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Abstract 


Thermal Hydraulic Performance Analysis of a Small 
Integral Pressurized Water Reactor Core 

by 

Stuart R Blair 

Submitted to flie Department of Nuclear Engineering on July, 2003, 
in Partial Fulfillment of the Requirements for the Degree of Nuclear Engineer 


A thermal hydraulic analysis of the International Reactor Innovative and Secure (IRIS) 
core has been performed. Thermal margins for steady state and a selection of Loss Of 
Flow Accidents have been assessed using three methodologies to account for uncertainty. 
The diennal hydraulic analysis has shown that the IRIS is designed with adequate 
thermal margin for steady state operation, the locked rotor/shafl shear accident (LR/SS) 
and for variants of the partial loss of flow accident. To treat uncertainties, three methods 
were used, ranging from conservative, deterministic methods, to more realistic and 
computationally demanding Monte Carlo-based methods. 

To facilitate the computational requirements of the thermal hydraulic analysis, a script- 
based interface was created for VIPRE. This scripted inter&ce (written in Matlab) 
supplants the existing file-based interface. This interface allows for repeated, automatic 
execution of the VIPRE code on a script-modifiable input data, and parses and stores 
output data to disk. This endows file analyst with much greater power to use VIPRE in 
parametric studies, or using the Monte Carlo-based uncertainty analysis methodology. 
The Matlab environment also provides powerful visualization capability that greatly 
eases the task of data analysis. 


Thesis Supervisor: Neil E. Todreas 

Title: Korea Electric Power Company Professor of Nuclear Engineering, Professor of 
Mechanical Engineering 
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Chapter 1 Introduction 


1.1. Objectives 

This thesis has two complementary objectives. The first is to present a tiiermal- 
hydraulic (T/H) analysis of a small, integral, pressurized water reactor (PWR) core. The 
second is to introduce a set of computational tools that are designed to both expedite the 
T/H analysis process as well as harness the power of modem computer hardvrare to allow 
more detailed and comprehensive studies by providing a script-based interface to die T/H 
analysis program VIPRE. 

1.2. The IRIS Reactor 

General Description 

The IRIS is a modular, integral, light water cooled, low-to-medium power (~ 350 
MWe) reactor, which emphasizes proliferation resistance and enhanced safety to meet the 
requirements defined by the U.S. Department of Energy for Generation IV reactors. A 
distinguishing characteristic of the IRIS is the integral design: The steam generators 
(S/Gs), reactor coolant pumps (RCPs) and pressurizer (PZR) are all contained within the 
reactor pressure vessel (RPV). This configuration is quite obviously very different from 
a conventional PWR where the S/Gs, PZR, and RCPs are all moimted outside of the 
RPV, connected by reactor coolant piping of varying diameter, all located within a 
containment. A simplified diagram of the IRIS RPV is shown in Figure 1. 
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Figure 1: IRIS Integral Reactor Conf^ration. 

Over the past decades there have been several projects involving the integral reactor 
concept. Many of the projects, as with many new reactor design projects in general, had 
terminated early in the conceptual, paper stage, while others have endured as viable 
entities for many years. Several integral reactor designs have been presented in the open 
literature.* A summary of past and current integral reactor projects is presented in 
Appendix 1. Advantages extolled by the designers of integral reactors include increased 
safety, more compact layout and reduced construction costs. 

Increased safety for integral reactors comes from one or a combination of the 
following design features: low power density, passive safety features of the containment, 
natural coolant circulation, and the central feature of the integral core configuration - no 
reactor coolant loops. The elimination of all reactor coolant piping removes that piping 
from loss of coolant accident (LOCA) possibility, and the probabilistic risk assessment 
(PRA) can ignore such breaks as initiating events. In the case of the CAREM-25, a 
preliminary PRA was carried out that indicated that due to the aforementioned design 
features the core damage frequency is two orders of magnitude less than that of a typical 
PWR, with attendant consequences three orders of magnitude less.^^^ 



* In this context, ‘open literature’ means: English language, non-proprietary publications. 
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The compact plant layout is derived primarily from the elimination of the reactor 
coolant piping and by placing equipment normally external to the RPV such as the S/G 
and PZR within the vessel. The elimination of the requirements for large on-site welds 
on reactor coolant piping, as well as the modular configuration of the reactor vessel 
assembly, is expected to lead to a shorter construction time. This, in conjunction with die 
overall smaller physical fooqirint, is expected to lead to lower construction costs. 

Thermal Hydraulic Analysis of IRIS 

A key step the design of a new reactor plant is the core T/H analysis. In this step, it 
is determined whether or not the fiiel can satisfactorily be cooled imder both nominal and 
accident conditions. 

From a T/H perspective, the IRIS core is somewhat of a departure from typical 
PWRs in that core power, specific power, linear power and power density are all lower 
than that of typical PWR designs. Some T/H parameters are provided for comparison in 
Table 1. 



Standard 

PWR 

IRIS 

AP1000 

AP600 

P/D 

1.32 

1.4 

1.33 

1.33 

Core power (MWth) 

3411 

1000 

3415 

1940 

Specific power 
(kW/kgHM) 

40 

20.72 

40 

29 

Linear power 
(kW/m) 

18 

12.9 

18.8 

13.2 

Power Density 
(kW/1) 

106 

51 

110 

79 


Table 1: Comparison of Thermal Hydraulic Parameters of IRIS to Typical PWR Desl^s. 


The core T/H analysis includes a study of steady state behavior, a sensitivity study 
that examines the IRIS model response to perturbations of key operational parameters, 
transient analysis of three types of LOG A events and a hot channel analysis that 
incorporates the uncertainty inherent in plant design parameters and combines them to 
provide conservative predictions on plant behavior during a set of transients. 

The hot chaimel analysis plays a central role to the core T/H analysis in tiiat it is the 
means by which design uncertainties are translated directly to evaluate the impact of such 
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uncertainty on the T/H acceptability of the design. Three separate methodologies are 
employed to perform this hot channel analysis in which different rules are applied in the 
combination of die imcertain parameters, as well as in the interpretation of the results. 

1.3. Computational Tools 

The number of computations that are required in a typical nuclear reactor core design 
is enormous. The invention of digital computers, their employment in nuclear design 
applications, and gradual integration into mainstream engineering use, has lightened the 
manual *pen-and-paper’ calculation required by the ordinary design er^ineer 
considerably. Softwwe tools’* constitute die interface between the engineers and the ever 
burgeoning computer power that is capable of performing billions of calculations every 
second. Software designed specifically for the purpose of T/H analysis allow ordinary 
engineers to harness dus computational power and perform their job - designing the 
nuclear reactor core - much more quickly than what was possible in die past. 

Despite these advances, codes designed for performing T/H analysis, and 
consequently the engineers viio use them, often fail to fully eiqiloit the capabilities of the 
machine on which they are being run. In many cases, this is a result of the way in i^ch 
the engineer is forced to provide inputs to die software, as well as the way in which the 
program communicates its results with the engineer. Text files with strict and torturous 
formatting rules are required to communicate program inputs. Output data is buried 
within a dizzying barrage of numerical results. The cheeqi, ubiquitous computers - each 
endowed with tremendous power - are largely idle while engineers, whose speed of work 
has not improved by large orders of magnitude during the computer revolution, chiefly 
spend their time trying desperately to create an input file that actually runs and labor 
furiously to create a single attractive plot from the mountain of output data. 

In this diesis, a set of software tools; a script-based interface - is introduced and 
demonstrated. Using diese scripts, input files, analysis code execution, output data 
parsing, and odier related tasks are performed ‘automatically’ in accordance with 
‘scripted’ logic. These scripts, to a large extent, allow die analyst to work more 

In flus thesis, ‘Software tools’ will often be colloquially referred to as ‘codes’. 
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productively with existing analysis codes to produce useful results more quickly. 
Additionally, because of the nature of the script-based interface, analyses can be 
conducted in ways that would have been completely infeasible without such an interface. 

1.4. Thesis Organization 

Following this introduction. Chapter 2 gives a thorough introduction to the Matlab- 
VIPRE Interface. This script-based interfece is sfcown to be a more powerful and 
versatile tool than that which is customarily provided with scientific software. Included 
is a detailed ^plication of this interface to die IRIS Tight core design. Additionally ideas 
are developed for extension of die Madab-VIPRE Interface to include other programs 
such as the fuel performance analysis code FRAPCON. A more complete documentation 
of the implementation details of the Matlab-VEPRE Interface is given in Appendix 2. 

Chapter 3 is a report on the diermal-hydraulic analysis of the IRIS Open core design. 
In addition to the detailed steady-state analysis, a complement of LOFA casualties are 
analyzed including a complete loss of flow accident (CLOFA), a partial loss of flow 
accident (PLOFA) where four of the eight installed reactor coolant pumps cease 
operating, as well as the locked rotor/shaft-shear (LR/SS) accident \^ere only one 
reactor coolant pump is incapacitated. The transient analysis is enhanced by a thorough 
uncertainty analysis where two established methodologies: the standard thermal design 
procedure (STOP) and the improved thermal design procedure (ITDP) are employed 
along with a third, relatively unestablished procedure: the Monte Carlo uncertainty 
procedure (MCUP) is used to provide a more thorough and accurate, albeit 
computationally demanding accounting of the inherent uncertainties of the core design. 

Chapter 4 presents the conclusions from the thermal-hydrardic analysis. In this 
chapter, a qualified determination is made outlining the extent to which the IRIS Open 
core satisfies thermal limits. A comparison is made between the conclusions that would 
be drawn from the use of different uncertainty analysis procedures which also outlines 
advantages and disadvantages of each. 

Chapter 5 provides an outline of recommended future work. Shortcomings in the 
present thermal hydraulic analysis procedure are highlighted along with potential avenues 


19 0/257 






for rectification. A discussion is given to possible future directions of the Matlab-VIPRE 
Interface along with related computational components. A bibliography is provided in 
Chapter 6. 

Followir^ the main body of the thesis is an extensive set of appendices that expound 
iqwn certain technical topics that are related to discussions present in the thesis proper. 
Prospective users and developers of the Matlab-VIPRE Interface are provided witii a 
more detailed description of the interface implementation details in Appendix 2. 
Extensions to codes such as FRAPCON and RELAP, and practical direction regarding 
script usage and implementation is provided in Appendix 2 - Appendix 8. Appendix 9 is 
given as a preliminary fuel cycle cost analysis of tiie IRIS Open core. This analysis is 
intended to be the starting point of a more thorough and comprehensive economic 
analysis of thelRIS fuel cycle. 
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Chapter 2 Thermal Hydraulic 
Analysis Tools_ 


2.1. Introduction 

For tiie purposes of performing a full thermal hydraulic analysis of the IRIS Open® 
core, it is necessary that a collection of computational tools be utilized. While paper-and- 
pencil computations are a necessary and important part in imderstanding local channel 
phenomena, the complexity that accompanies detailed, predictive calculations does not 
allow hand calculations. For this project, the VIPRE 1-mod 2 sub channel analysis code 
(reference [2]) was used to evaluate in-core channel conditions during steady state and 
transient conditions. For transient calculations, the system simulation code RELAP^^^ 
was utilized to provide necessary core boundary conditions. 

VIPRE and RELAP are codes typically used in the thermal hydraulic design of a 
nuclear reactor. They are both programmed almost entirely in standard Fortran 77, and 
are interfaced via ASCII text-based files for both inputs and ou^uts. The text-file based 
interface is common for many other codes used in reactor design such as: CASMO^"*^, 
SIMULATE, MCNP^^^, and FRAPCON^^l This list could easily be e}q)anded to include 
dozens of other codes developed by nuclear engineers, as well as hundreds of others 

* Here, the word OPEN is used to distinguish diis core design from an altemative: IRIS Tight, that will be 
introduced in this chapter. 
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crafted among the scientific community in general. These codes are an embodiment of 
an enormous quantity of experimental data and theoretical knowledge, custom tailored to 
the solution of problems in nuclear reactor design. 

This chapter will focus on the inadequacies inherent with the aforementioned file- 
based interface to analysis codes, and the script-based interface that was created as a 
replacement 

2.2. User Interface 

For any given software package, in many ways, the user interface is the code. As 
techmcal software users, we customarily spend a good deal of time lea rning the general 
principles involved with the internal workings of the code. Despite this, there are plenty 
of engineers vdio use complex codes such as CASMO or SIMULATE without being able 
to write down anything that represents in a significant way the sets of equations being 
solved internally to the code. The filing that matters most to file user is: What can this 
code tell me? Practical considerations also include: How do I ask the code questions? 
And: In what ways are the answers provided to me? The above questions can be 
considered to be a good definition of the code user interface. In this section, I discuss 
various means that codes have, over time, been designed to interact with users - the 
interface, and the impact that this interface has on usability of the code. 

Command-Line Arguments 

Co mm a nd line arguments represent, probably, the most basic way that a user can 
customize the behavior of a compiled program wifiiout making changes to the source- 
code itself. Programs can be extended in this way to allow more usefulness and 
flexibility. A typical example of fiiis interface familiar to many engineers would be: 


g++ -o my_program myjprogram.cc -lmy_mcludes/ 

This is a command to invoke the GNU-C-H- compiler firom a LINUX Bash shell. 
The command line arguments tell the compiler to create an executable called 
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/wj jjrogram from the C-h- source file my j)rogram.cc adding to the search path for 
header files the directory myjncludes. 

In principal there are really no limitations on how much information can be 
exchanged between the user and the code via this interface. Ihe practical constraints, 
however, are many. The user can only reasonably be expected to manually enter a small 
number of command-line arguments, or ‘options’, with each execution of the code. 
Secondly, these arguments do not persist between code executions. They must be re¬ 
entered each time.’’ While there are likely furdier operating-system-dependent 
limitations, it is clear that th^e are severe practical constraints on the user interface fiiat 
is provided only on the command line. Similar limitations exist if the program output is 
to be directed only to the user terminal. These constraints lead programs to migrate 
towards a more flexible, file-based interface. 

File-Based Interface 

The file-based interface has its roots in the very earliest days of stored-program 
computers. Text files, almost always with a very rigid format, were required to provide 
input data for the code to process. In a similar style, the fiuits of the program’s labors 
would be deposited in a file for the user to sift through and glean desired information. 

This program has the advantage that a great deal of input data can be provided 
allowing for extensive customization of program behavior. Both the input and output 
data are persistent, in that it does not disappear between program runs. 

This approach has several disadvantages. First, the format required for the input data 
is typically such that a considerable amount of time and care must be put into the 
preparation of the input data. This is effort beyond that required for the formulation of an 
appropriate physical model. In addition to choosing appropriate assumptions, geometric 
discretization, and physical correlations, the user is required to encode these selections to 
the precise specification of the application program. A user making any syntactic 

Thou^ peth^s it is wordi noting that the example given is an example where a more useful interfece is 
provided: a Makefile - a special file that is read by a program called make which automates the building 
process (i.e. prq>rocessing, compiling, assembling, linking) of creating an executable program from a C++ 
source file. This ^stem is, for dl intents and purposes, a script-based interfrice with &e Makefile as the 
(often automatically generated) script. 
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mistakes, even those as simple as a missing comma or capitalized letter, can ejq)ect 
abrupt program termination accompanied with characteristically ciyptic error messages. 
Finding and correcting mistakes in the input file can take anywhere from hours to weeks. 
Secondly, and as a corollary to the first, most modifications to tiie input data would 
require a similarly large amount of tedious work - devoid of scientific reward or 
gratifying insight - with little benefit gained fi:om having done this work already. As an 
example, for the VIPRE input file, a conceptually trivial change to core geometry such as 
an adjustment in the fuel pitch-to-diameter ratio, results in hours spent revising the input 
file. Thirdly, these modifications have to be performed manually. No hope of 
automation is provided. 

The file-based output format is not without disadvantages of its own. VIPRE 
produces, for the benefit of the user, a very detailed collection of information regarding 
the calculated state of the working fluid in each sub-channel. For the typical simulation 
that was performed for the IRIS Open core, the outi>ut file for a steady-state calculation 
woxild reach approximately 800 KB in size. While this is not terribly large, it is more 
tiian is easily dealt with in the case of printed ouq)Ut. In addition, as text, it is 
inconvenient to transfer this data to an effective visualization or data analysis program.® 
For more complicated situations such as a transient, the output data file could grow to be 
as large as 200 MB. At this time, it is beyond the capabilities of ordinary text-editin g 
programs merely to open the file to view its contents, to say nothing of the analysts’ 
ability to actually manipulate this data and form useful conclusions. 

Graphical User interface 

At the present time, most respectable, newly authored, commercial and industrial 
purpose codes come equipped with a graphical user interface (GUI) of familiar design. 
Though the details of this interface vary among different operating systems, most 
packages conform to a standard of menu layout and task or ganizati on that have made user 
experiences intuitive and ea^ to learn. 


* Despite any inconveniences, scientists have predictably become very adept at writing simple, custom 
programs designed to extract desired data from text-based ouq>ut files. 
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Modem GUIs solve many of the problems associated with the file-based interface. 
Input data can often be entered in an interactive, visual environment. Choices for input 
variables can be limited, with only valid choices available. These environments focus 
heavily on ease-of-use and reduce considerably the time lost in the model formulation 
stage of the design. Often, provisions are made to allow for especially simplified 
execution of routine tasks. Output data is commonly post-processed and presented to the 
analyst in graphs, plots and other useful ways so that incredible insight can be gleaned 
fi:om enormous data sets that a decade ago would have been completely unmanageable.^ 

Scripted Interface 

The alternative to a file-based or GUI presented in this chapter is the script-based 
interface. A script-based interface is designed in such a way, that the inputs and outputs . 
of a particular code, like VIPRE, are provided in the form of programmed function inputs 
and outputs. The VIPRE code itself becomes a functional part of a separate code (script) 
written by the analyst with the aim of performing the desired analysis. Examples of a 
script-based interface development for other codes exists in the recent literature. 

A real shortcoming in both GUIs and file-based-interfaces is that they restrict the 
kind of analysis that can be done. Put differently; fiiey restrict the types of questions that 
an analyst can ask. It is interesting that such a restriction would have its roots in the user 
interface, rather than in the code itself - but this seems completely to be the case. VIPRE 
is capable of answering many interesting questions: What is the maximum temperature 
at the centerline of the hottest rod? How close is the core to DNB? WTiat is the pressure 
drop across the core? What is the fluid flow velocity in the core? These questions can be 
answered and communicated using the file-based interface as well. But the analyst, with 
a file-based interface, cannot, in any reasonable amount of time determine: 

What is the maximum aliowabie core power such that i do not exceed a 60-psi 
pressure drop, keep core outlet quality below 5 percent, and restrict flow velocity 
to below 10 m/s, while maintaining MDNBR above 1.4? How will this change as I 
adjust the fuel lattice pitch and rod diameter? 


^ Scientific data visualization has become a sub-field of scientific computing in and of itself. 
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But, these are exactly the sorts of questions that an engineer needs to answer for a 
thorough thermal hydraulic design - and VIPRE is fully capable of providing the answers 
provided that it is a^ed in the right way. The script-based interface was created for this 
puipose. 

In this instance, the script-based interface is built on top of the file-based interface. 
The file-interface is m a int a ine d, but the input file is automatically generated by the script- 
interface based on information programmed by the analyst. S imilar ly, thro ugh minor 
modifications to the VIPRE source code, key computational ou^uts are directed to data 
files that are easily parsed by the script interface and presented to die analyst 
(programmer) via data structures in the scripted language. 

2.3. Matlab-VIPRE Interface 

General Description 

The particular script-base interface created for this project will be referred to simply 
as the Matlab-VIPRE Interface. The scripting language chosen is Matlab.® As an aid to 
the programmer in assembling and manipulating input data, die ubiquitous spreadsheet 
program Microsoft Excel^ is also used. A schematic representation of the Madab-VIPRE 
Interface is provided in Figure 2. 



F^re 2: Schematic representation of the Matlab-Vipre Interfiice 

* Matlab is a registered trademark of The Math Worics, Inc. Natic, MA. 

^ Excel is a registered Iradanaik of Microsoft Corporation, Redmond, WA. 









Before the Matlab interface was created, a usual way that the analyst organized the 
input data was by using Excel. Typically, all of the input data would be carefully 
structured in die spreadsheet in such a way that much of the actual input file for VIPRE 
could be literally cut-and-pasted out of the spreadsheet. These ‘Excel-based interfaces’ 
are often fairly sophisticated in that many of the calculations required to implement 
changes in rod diameter or lattice pitch are propagated through spreadsheet formulae. 
This greatly expedites any core geometry changes that must be made. A screen-shot of 
tilis typical interface is provided in Figure 3 



Figure 3:Microsoft Excel Spreadsheet With VIPRE Input Data. 

Implicit in the initiation of a large effort to provide a script-based interface to VIPRE 
is the desire to minimize the amount of work that must be done. At the outset, no 
coherent design existed, primarily due to the fact that there were many unanswered 
questions as to how eveiyfiiing would be done. First and foremost was the question of: 
What language will be used for the scripting interface? How will this interface be tied 
into VIPRE? How will the outputs of VIPRE be dealt with? Each of these questions was 
dealt with individually, but the answers all rested on some key early decisions. The first 
of which was that die initial input for the scripted interface, would be provided through 
Excel. 
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For Ae IRIS open design, scientists at Westinghouse had, as of the spring of2002 
spent a considerable amount of time in developing an acceptable VIPRE model of the 
IRIS core. This model was organized in a set of Excel spreadsheets vhich together, 
greatly simplified die process of generating a correct input file for VIPRE. The detailed 
geometric description of the rods, channels, correlation selections, power profile 
specifications, and coefficient calculations were performed on separate worksheets. The 
data provided was then collected on a single worksheet that was structured in the required 
format for a VIPRE input file. Conversion of this worksheet to a valid input file 
consisted of systematically converting this file to an ASCII text file. 

The initial aim of tiie work was to devise a way to somehow automate tiie process of 
converting tiiis worksheet to a text file. Matlab was chosen for this task. The primary 
reason for this choice was the powerful assortment of both high and low-level 
Input/Output (I/O) &cilities provided by this program as well as extensive 
interoperability with other Windows* programs’* via ActiveX technology. So the decision 
was made that Matlab should somehow be used to automatically extract the input data 
from Excel, and then generate a text file with exactly the correct format as required for 
VIPRE input 


Excel 

Matlab 

Several Worksheets Containing Model 
Parameters and Data 

Communicate with Excel via ActiveX 
Controls to extract input data 

Perform simple computations to adjust the 
input data based on model parameters: e.g. 
re-compute channel flow area after 
changing pitch or diameter 

Using communication pathways, modify 
model parameters such as chaimel pitch or 
diameter as required by script 


Table 2: Matlab and Excel Interaction in Matlab Vipre Interfiice 


Conveniently, Matlab has, through the use of ActiveX controls, the built-in ability to 
address a specific Excel spreadsheet. The resulting object within the Matlab workspace 

* Windows is a registered trademark of Microsoft Corporation. 

'' For example; Excel 
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context provides handles to all of the spreadsheet data and ftinctionality. Low-level 
functions are thus available for extracting data from the spreadsheet, directly into the 
N^tlab workspace. A ^ical set of function calls using this capability are: 


[xl,xl_wb_specific] = get_spreadsheet(filename); 
input_sheet = get{xl_wb_specific,'Sheets' , 'input'); 
viprel.kase = get_cell_value(input_sheet,'A32'); 
geom3(i).dx = get_sheet_row_col{input_sheet,44,index); 


Once this data is extracted, it is saved to Matlab-style data structures very analogous 
to the C-type struct. A detailed script was written to carry out this action, therefore, the 
action of extracting all of the required input data from a specified Excel workbook, is 
reduced to the invocation of a single script 

Next it was required to convert the data, now in the Matlab environment, to a text 
file ready to be used by VIPRE. Communication between the user-written script and 
VIPRE would take place entirely through the file system.' Another script was written 
specifically for this purpose. Low-level file I/O facilities are provided with Matlab very 
similar to equivalent functions in C. Each input field to be provided to VBPRE, referred 
to as a ‘card’, is written to the text file, with the correct format, and in the correct order. 
Separate low-level functions were written that would write the data for each individual 
field. A larger script was written to orchestrate the entire process.^ In this way, having 
extracted the input data from Excel, this function would cany out all actions required to 
generate the required input file and write the file to the hard-disk. Additionally, using the 


' i,e. data to be transferred from the Matlab workspace to tire VIPRE input context and vice versa would 
first be written to a file by one program, and fiien read from the file by the ofrier. 

^ This larger, orchestrating script is required to enforce the required order of input in VIPRE. The 
individual input cards in VIPRE are not identified. Rather, o^y a single card at the beginning of each 
‘section’ of the VIPRE iiqruL (Example: the first card of the geometry section has, as the first input 
variable, die flag ‘geom’ - in this way, the start of the geometry section is identified.) Once the input 
section is identified, the remaining cards within the individual section follow in an order that can be 
(fynamically determined from the cards as they are read within that section. The data must be entered in a 
w^ that preserves this order, or an input error will be produced by VIPRE. 
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high-level I/O of Matlab, the input data itself could easily be stored to hard-disk and 
recovered,*' allowing the same input data to be used to generate multiple input files. 

It is strai^tforward to manipulate the input data within die Matlab environment 
simply by variable initialization and assignment In this way, the input data itself could 
be changed within the Matlab environment prior to writing it to disk. As an example of 
this important capability. The following command changes the core mass flux to 


change_input (var_f ile_name, • oper5. gin' ,2.5) 


This capability is fundamental for many of the capabilities that a script-based 
interface should provide. More significantly, diese manipulations to the input data, and 
consequently the input file, could be scripted and automated, so that the input data could 
be adjusted automatically any number of times by high-level scripts wi thin Matlab. This 
created the groundwork for multiple, systematic VIPRE simulations. 

These systematic VIPRE runs are the key to the power of the script-based interface. 
VIPRE takes on many of the characteristics of a built-in Matlab function, so more general 
algorithms developed and in^lemented using the Matlab language can easily be adapted 
for use with VIPRE. If one wants to perform a general parametric analysis, all of tiie 
capability is present to automate tiie systematic coverage of the parameter iq)ace desired. 
If one wants to perform an optimization study of a particular core, the ability to 
manipulate the input data for VIPRE and examine the resiilting output is exactly the 
behavior required. 

Once the input file is created, it is then required that the input file be provided to 
VIPRE for processing. The method for this is simply to place the input file in the same 


Using the ‘save’ and ‘load’ functions provided in Matlab, this process could be accompli^ed in a !wn£l<» 
line of code. 

* The first argument is the name of the ‘ *.mat’ file that holds the input data, the second argument must be a 
string variable that is the specific variable to be modified, the third argument is the value that tiie variable is 
to take. Using tiiis function preserves the input data file in tiie ordw required for proper input file 
generation. 






directory as VIPRE.“ The input file is named, logically, “input.txt”, and the executable is 
invoked. Ass umin g that die program runs properly and no errors arise, a set of ou^ut 
files are created by VIPRE and deposited in this same directory. The sequence of events 
is: 

• Matlab extracts input data from Excel spreadsheet and writes a valid input file to 
hard-disk. 

• Second, through built-in functions, Matlab copies this input file to the directory 
where the VPRE executable resides. 

• Matlab causes VIPRE to be invoked, and then dispatches in an appropriate 
fashion, the output data generated. 


Matlab version 5.3 has no built-in function that invokes an outside executable 
directly. ” Matlab has been, however, endowed with the extensibility feature whereby 
C/C-H- or Fortran functions can be written, compiled as dynamic link libraries, and the 
resulting functions called directly from within the Matlab environment. The solution is 
thus, to write a trivial C program that makes the proper operating system call to invoke 
the VIPRE executable, and then call this function from within Matlab. All that is left 
then, is the processing of the ouqjut data that is also performed by a script. 

Several minor modifications of the VIPRE source code were required for the 
completion of this research. They are simply enumerated here": 

• Several new output files were created that would contain only the numeric data 
generated from various routines within the VIPRE program. This was to simplify 
the task of parsing the ouqjut data from within Matlab 

• The input and output files were changed so that they had the ‘.txt’ postfix to allow 
simplified handling within the Windows environment. 

• The maximum allowed number of transient time-steps was increased to 500 from 
the previous limit of 10. 

As can be seen, these modifications are all fairly straightforward in nature and had 
no significant impact on the running of the code and, in particular, in the reliability of the 
results produced. The last modification was absolutely essential as the transients we 
hoped to run were discretized into over 400 time-steps. 

" This is exactly what one would using only the file-based interfiice. 

“ Version 6.5 now has die cq>ability of directly calling the operating system by re-directing command line- 
inputs to die operating system shell. 

° Detailed descriptions and dociunentation of these changes is provided in Appendix 2. 
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Low-Level Routines 


Numerous low-level routiiies were required for the proper operation of the interface. 
Each input-card for the VIPRE input deck is written to the input file individually. The 
routines that complete this task are typical of what one would expect for a C or Fortran 
statement for writing to a file. For exanq)le, the following is a fimction for writing the 
VBPRE input card: OPER.5 to the input file: 

function gen_oper5(fid,operS) 

pref » sprintf (•'%7.4f,',oper5.pref); 
hin = sprintf('%7.4f,',oper5.hin); 
gin = sprintf('%7.4f,oper5.gin); 
pwrinp = sprintf('%7.4f,'/OperS.pwrinp); 
if operS.hout == 'empty' 
hout = 'O'; 
else 

hout = nuin2str (operS.hout) ; 
end 

entry = street(pref,hin,gin,pwrinp,hout); 
count = fprintf(fid,'%s \n',entry); 


The fimction is provided a handle** to the VIPRE input file: ‘fid’, and a copy of the 
Matlab variable holding the input data for the VIPRE input card ‘OPER.5’. The fimction 
merely formats and writes this data to the hard-disk. Similar routines are provided for 
other VIPRE input cards. 

Low-level routines were also required for communication between Matlab and 
Excel. In particular, it became necessary to have easy ways to obtain an interface to an 
existing Excel worksheet,** ‘grab’ data finm cells within that worksheet, and modify cell 
entries fiwm within the Matlab environment. These features are critically important to the 
integrity of tiie scripted interface. If they were not provided, calculations would have to 
be interrupted while changes are manually made to the spreadsheets. In general, any 
operation that cannot be performed via the Matlab script, fimdamentally limits the types 
of analysis that one can do - the limit being the requirement for manual intervention in 
the analysis process. Tasks that are customarily carried out by hand - steam-table look- 

*’ In Ais context word ‘handle’ means a typt of variable throng which a referenced object (data structure, 
program, function) can be accessed and manipulated. 

** In Ais Aesis, Ae word ‘worksheet’ will be used to refer to a particular sheet within an Excel workbodc. 
The word ‘workbook’ is used to refer to Ae Excel file (e.g. my_woik.xls). 
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ups, graph-reading and changes to spreadsheets — must be automated, or the interface will 
be incomplete and the expected benefits will not be obtained. 

High-Level Routines 

Following the development of the low-level Matlab scripts to carry out the necessary 
tasks to perform an individual VIPRE run, higher-level scripts were created to perform 
common tadcs, some of which have already been mentioned. These scripts are formed by 
cobbling together the various lower-level tools and are actually quite powerful. Some of 
these scripts are emunerated here^: 

• (jet_excel_input.m: this is actually a fairly low-level script, but is powerful in 
that, provided the arguments of a specific Excel workbook (and worksheets) 
where ^e input data resides, all of the input data is extracted from the specified 
workbook, and stored to disk in Matlab style data structures. 

• Generate_input_file.m; This script calls the necessary low-level functions 
required to generate a complete VIPRE input file. 

• Parse_viper_output.m: This script post-processes the VIPRE generated output 
files and places the data in Matlab style data structures and stores the data to disk. 

• VIPRE_run.m: This script carries out die task of copying the input file to the 
directory where the VIPRE executable resides, callmg the required function to 
invoke VIPRE, and calls Parse_viper_outputm. 

It should be clear to the reader, that the functionality provided by these scripts allow 
one to quickly pre-program (‘script’) a sequence of useful VIPRE activities. In all cases, 
input files are created without the usual human flaws,^ and there is no human intervention 
required to collect the output data. In addition, Matlab is endowed with powerful plotting 
functions that make visualization of the results relatively simple. This eliminates the 
tedious work of extracting the data from the voluminous output files, and allows more 
time for actual analysis. Several Matlab-VIPRE Interface applications are provided in 
Appendix 2, along with the entire source code for the Matlab-VIPRE Interface. 


' Full listings of the code for fliese functions are provided in Aiq)endfac 2. 
‘ Missing conunas, misplaced decimal places, etc... 


33 0/257 






2.4. Modelling the IRIS Tight Core With The 
Matlab-VIPRE Interface 


The Matlab-VIPRE Interface described in this chapter provides a potent tool for 
dealing vrith tedious and error-prone tasks associated with computational analysis: input 
file preparation and modification, gathering data fix>m output files and visualizing results. 
As an example of the power and convenience of these features, a short analysis is 
conducted to e3q)lore some of the behavior of the IRIS Tight Core design.^^^^’®^ 


The IRIS Tight Core design is intended to be an upgrade to the current IRIS design, 
referred to as IRIS Open. The IRIS Tight Core design is so called because of the 
relatively ‘tig^it’ geometric configuration of the fuel assemblies, with a currently designed 
pitch-to-diameter ratio (P/D) of 1.156. This design is intended to generate more power, 
have a longer cycle length and comparatively favorable economics compared to the 
reference IRIS Open design, while maintaining the same physical core size. Relevent 
design characteristics of the IRIS Tight core as compared to the IRIS Open and a 
Standard PWR are given in Table 3. 


Standard 

PWR 


IRIS 

OPEN 


IRIS 

TIGHT 


P/D 


1.32 


1.4 


1.156 


H/HM 


3.4 


1.29 


ODROD (mm) 


9.5 


10.74 


Enrichment (w/o 235U) 


3%-5% 


~5% 


-14% 


Bu (MWD/KgHM) 


~50 

(Reactivity 

Limited) 


40 

(Reactivity 

Limited) 


70 

(Metaliurgicaily 

Limited) 


Core power (MWth) 


3411 


1000 


1661 


Specific power 
(kW/kgHM) 


40 


20.72 


25 


Linear power (kW/m) 


18 


12.9 


11 


Power Density (kW/l) 


106 


51 


65 


Table 3: Comparbon of Core Characteristics. (Source: (10]) 

Notice that, in this table, there is no specification of the fuel assembly lattice pitch 
other than tiirough the given P/D and rod outside diameter. Thermal hydraulic analysis 
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presented in reference [10] demonstrates that for the nominal rod diameter of 9mm and 
the operational conditions given in Table 4, the MDNBR is above a prescribed thermal 
limit of 1.50.* 


Parameter 

Value 

Linear Power 

11 kW/m 

Coolant Mass Flow Rate 

18.01 Ibm/sec ( 70 % nominal for l/b*** 
assembly) 

System Pressure 

2220 psia 

Core Inlet Temperature 

561.6 ®F 


Table 4: Operational Parameters for IRIS T^ht Thermal Limit Calculation. 


The question to be answered is: how does the computed MDNBR change as fuel rod 
outside diameter is changed. This analysis incorporated the following additional 
constraints: 

• The P/D is maintained constant at 1.156 by adjusting the rod pitch to compensate 
for each rod diameter change. 

• The guide-thimble diameter is adjusted to be the same as the fuel rod diameter in 
all cases. This ensures that a reasonable configuration will be maintained in 
channels with juxtaposed fuel rods and guide-diimbles.“ 

• The wire-wrap diameter is adjusted so that the wire maintains contact with 
adjacent fuel rods. After die rod diameter and pitch are adjusted, the wire wrap 
diameter is set to be equal to: 


* The detailed development of the rationale for the given diermal limit is given in reference [10]. 

“ Le. the fuel rods and guide thimb les will not geometrically overlap - as could happen in the case where 
the fuel rod diameter is reduced, then pitch is reduced so that the fuel rods and guide thimbles are brought 
closer together. Since the P/D > 1, the pitch will be reduced by a larger amount than the fuel rod diameter 
is reduced, therefore rod overlap is possible if the guide thimble diameter is not also reduced. The guide- 
thimble is, for the reference design identical in diameter to the feel rod. For simplicity, this relationship is 
maintained. 
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Eqaation 1 


wire-wn^ 


= P-D 


Juel^rod 


>^4iere: 

P = pin pitch 

Dfuei_rod = fuel rod diameter 


• The specific power is maintained constant by adjusting fiie linear power with each 
rod diameter change in accordance with the following: 


Equation 2 


<1 


fml _pdkt 


Where: 


q’ 

is the Linear Power 

a 

is the Specific Power 

Pm 

is the fuel density 

l^fael_pettet 

is the fuel pellet diameter 


The specific power is to be held constant, and the fuel density is assumed constant, 
therefore the linear power can be equivalently expressed: 


Equation 3 

^ “ ^^fael_pettet 

where: c = 

4 

To adjust the linear power to maintain constant specific power with different rod 
diameters therefore: 


Equation 4 


n2 

^pellet 


rp 

fitel _ pellet _new 




fuel _ pellet _ new 
^fuel _ pellet _o 
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The coolant mass flow rate is adjusted to maintain a constant enthalpy rise across 
the core in accordance with the following: 


Equation 5 
q'L = mAH 

where: 

L is the channel length (ft) 
m is the channel coolant mass flow rate (Ibm/sec) 
AH is the channel coolant enthalpy rise (BTU/lbm-°F) 

For channels of constant length, and constant enthalpy drop: is a constant. 

An expression for mass flow rate as a function of the new and reference linear power is 
therefore: 


Equation 6 










According to the above procedure, the fuel rod diameter is perturbed from the 
n ominal value of 9mm over the range: 8.5mm to 9.7mm. 

To perform this analysis by hand would an arduous task. Though it is straight-forward to perform 

die computations outlined in 


Equation 1 to Equation 6, the modifications to die core geometry result in extensive 
changes to the VIPRE input file. Every channel characteristic such as flow area, heated 
and wetted perimeter must be updated to reflect the new geometry. Similarly, the 
interchannel gap length and width must be updated. Other modifications to the model are 
also required, but in modifying only the fuel geometry hundreds of numbers must be 
successfully computed and transcribed into the jq)propriate VIPRE input file format. 

By contrast, with the use of the Matlab-VIPRE Interface, a relatively short, high- 
level script is required. The main body of this script is given here: 

%vipre_diam_y ary, m 

addpath (* c: \inatlab_svl3\work\research^ vipre transient tools *); 






spreadsheet_filename « streat (pwd, ’ \vipre_inpvit_spreadsheet_updated_2 .xls *); 

%cpen the excel file ^ 

txl,spread_sheet] = get_spreadsheet(spreadsheet^filename); 

SPECIFIC_POWER = 25; %)cW/kg 
REFERENCE SPECIFIC POWER * 25;%kW/kg 
P_D *= 10.4/9; 

diam_conversion_factor * 1/25.4; %25.4 mm/inch 

geom_sheet - get(spread_sheet,'Sheets *,’Channels’); 

oper_sheet « get(spread^sheet,’Sheets’,’oper’); 

diameter_range * get(geom_sheet,’Range’,’e8 * ^’e8’>; 

gt_diameter_range » get(geom^sheet,’Range*,*el3*,’el3M; 

pitch^range * get(geom^sheet,’Range’,’e20’,*e20’); 

wire_wrap_range - get(geom_sheet,’Range’,*e21*,'e21*); 

initial_flow_area « get_cell_value(geom_sheet,’c443’);%in square inches 

nominal_j)ower * get_cell_value(operasheet,*e8’); %corresponds to a specific power of 25 

kW/kg 

nominal_flow_rate - get__cell_value(oper_sheet,’d8’); ^Ibm/sec 

nominal^mass^flux « (noininal_flow_rate*3600*le-6*(144)♦(1/initial flow_area)); %in 
Mlbm/hr-ft^2* 

var_file_name * * test_jac_var’; 
input_file_name - *test_jac_input’; 

%input parameters in mm: 

N<»4INAL_PITCH « 10.4; 

NC»dINAL_ROD DIAMETER - 9; %MM 
NOMINAL_GT_DIAMETER **9; %mm 

NOMINAL_WIRE_WRAP - NOMINAL^PITCH - NOMINAL_ROD__DIAMETER; 

%VARIATION « 0.5; %MM 
NUM STEPS * 7; 

LOwiR_ROD_DIAMETER » 8.5; 

UPPER^ROD^DIAMETER = 9.725; 
test_mdnbr » zeros(2,NUM_STEPS); 
t€st_heat_flux = testjndnbr; 
test_eq_quality ■» test_mdnbr; 
test^chf » test_mdnbr; 
channel_heat_flux » zeros(48,NUM_STEPS); 
testj>wrinp * zeros (NtJM_STEPS, 1); 
test_gin « zeros (Kt3M_STEPS, 1); 
test_flow_rate ■ zeros (NtJM_STEPS, 1); 
test_flow_area ■ zeros(NUM^STEPS,1); 

diam^space^si * 1 inspace (LOWER_ROD_DIAMETER,UPPER_ROD_DIAMETER,Nt7M_STEPS) ; 
diam_space_brit * diam_conversion_factor .* diain_space_si; 

for i - 1:NDM_STEPS 

set(diameter^range,’Value*,diam_space_si (i)>; %next diameter value 
set(gt_diameter_range,’Value’,diam_space_si(i)); %keep the guide thimble moving too 
% set the new fuel pitch to maintain P/D *== 

teit5?_j)itch ■ diam_space_si (i) *P_D; 
set(pitch_range,’Value’,ten^jpitch); 

set {wire__wrap_range,’Value’, teii^_j)itch - diain_space_si (i)); %set wire-wrap diameter 

% =i^=ss=:=t =s»==S==6SSSS==SI=5S=ssajsatasssssi 51 =« a =g==s=8===iss 

invoke(spread^sheet,’Save’); 

get_jacopo_excel_input (spreadsheet_filename, var_file_name, spread_sheet) ; 

% set the new linear heat rate to maintain power density 

test_pwrinp(i) * (SPECIFIC POWER/REFERENCE_SPECIFIC_POWER) * nominal^ower * 
(diam_space_si (i) /NC3MINAL_ROD_DIAMETER) ^2; 

change_input <var_f ile_name, • operS .pwrinp’, test_pwrinp (i)); 

%===: set the mass flux so that delta T is constant ==*=b=b=bbb=555s=bi 
test_flow_area(i) * get_cell_value(geom_sheet,’c443’); 
test_flovi_rate (i) « (testjpwrinp (i) /nominal^power) * (nominal_flow_rate); 
test_gin(i) « test_flow_rate(i)/test_flow_area(i); 
change_input(var_file_name,’operS.gin’,test_flow_rate(i)); 

generate_input_file {input_file_name, var_file_naine); 
vipre_run_jon (input_filejname,var_file_name); 
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%coll6Ct run data into workspace variables 
load channel_data; 

testjmdnbr(:/i) - corr_mdnbr; 

end 

set (diameter_range, * Value* rNOMlNAL_ROD_DIAMETER) ; %set the value back to what it should 
be 

set (gt_diameter__range, * Value *, NOMINAL_GT_DIAMETER) ; 

set(pitch_range,*Value*,NOMINAL_PITCH); 

set (wire_wrap_range, 'Value* ,NOMINAL_WIRE_WRAP) ; 

invoke(spread_sheet,* Save*) ;%so the program doesn't ask me 

invoke(spread_sheet,'Close*); %close the file that I was working with 

delete (xl) ;%delete the active:-: server object 


The desired relationship between MDNBR and rod diameter subject to the 
constraints of constant specific power and constant enthalpy rise is given in Figure 4. 


MDNBR vs Rod Outside Diameter 



Figure 4: IRIS T4;ht Core MDNBR vs Rod Outside Diameter. 

The main feature of this result is that the MDNBR is reduced as rod diameter is 
increased and correspondingly improved as the rod is made smaller. The DNBR limit 
established in the design of the IRIS Tight Core is 1.50. It can be seen fi’om Figure 4 
that, in light of diis limit, die maximum permissible rod outside diameter is 9.6 mm. 

Since mass flow rate is adjusted to maintain a constant enthalpy rise across the core 
for the different rod diameters, and the axial power shape is maintained constant, die 




equilibrium quality of the coolant is constant for a given axial level as rod diameter is 
changed. Because of this, the change in MDNBR for varying rod diameters is e3q)ected 
to be dominated by changes in rod surface heat flux. 

The rod heat flux is influenced by the changing rod diameter in two ways: by 
changes in die rod surface area, and changes in linear power for a given rod. The change 
in linear power vdth changes in rod diameter is shown directly in Equation 4. The 
surface heat flux for a rod widi a given linear heat rate is: 

Equation 7 


^ tiD, 


where: q' is the heat flux 


rod 


It can be seen by inspection diat, for a constant q ', q" is dereased as rod diameter is 
increased. 

Combining Equation 7 with Equation 4,'^ the change in heat flux with changing 
diameters widi a constant specific power is shown: 


Equation 8 




I new ^ 


^TOdo 


^9 ^rod new . 

*^rod o 


nD, 


rod new 


nD, 


rod new 


^new _ 

ql 


id), 


rod new 


qo 


rod new 


^rod_o 


id). 


rod o 


This expectation dial q" will increase if the new rod diameter is larger than the old 
diameter and consequentiy die MDNBR will decrease is borne out in die VIPRE analysis 
results. 

The purpose for this section was to demonstrate the power provided by the script 
interface. This task, while straight-forward conceptually,'^ would be tedious and time- 
consuming to perform by hand. In contrast, this analysis was conducted rather quickly 


'' Note that Equation 4, q' is given in terms of the fuel pellet diameter, where in Equation 7, the heat flux is 

givoi in terms of the fuel rod diameter uliich includes the fiiel-clad gap, and the gap thickness. The fuel 
model used in tiiis analysis sets tiie fuel rod diameter to be a constant multiple of the fuel pellet diameter. 
Since tiiese equations idtimately involve the ratios of these quantities, fuel rod diameter and fuel pellet 
diameter can ^ used interchangeably provided they are used consistently. 

* ...And tiierefore fiurly easy to program... 
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with the script-interface and could easily be modified to perform a wide variety of other 
interesting analyses according to the user’s need. 

2.5. Extensions Of the Interface to Other 
Codes 

The methodology used in this ^plication for providing a scripted interface to VIPRE 
can be applied many other codes used within the Nuclear Engineering Department at 
MIT. This section outlines script-based interfaces generated for the fuel performance 
code FRAPCON and the plant simulation code RELAP. 

There are two features in particular that facilitate the creation of a script-based 
interface for a given code. First, the code must normally utilize a file-based interface. 
While this is a common feature among legacy codes, most contemporary programs 
employ a GUI and the primary method for providing input data and invoking the 
execution of the program. Unless special provisions where made in the creation of the 
program,* there is no ability to provide input data, or initiate the analysis portion of the 
program externally to this GUI. This makes the incorporation of a script-based interface 
impossible. 

Second, the source code^ for the program should be available and in a form that 
eases source code modification.* While this is not essential, it is very helpful to be able 


* There exist standard methods, when developing for a Windows environment, to provide fimctionality that 
allows one’s program to run as an ActiveX Server. This would allow the script to possibly act as an 
ActiveX Client diweby making the desired behavior of automated modification and execution of portions of 
the program possible. An example of a program with fliis capability is Microsoft Excel - this is Ae reason 
why Matlab is able to acess and modify Excel spreadsheet vdues fix>m wifiiin Matlab. This same provision 
e;qx>ses much of the functionality of Excel. For example. Excel woficbook functions can be called and 
applied to data passed fix>m Matlab, with fiie result returned to Matlab. 

^ It is understood that in the case fiiat the original code developers are a company that intends to profit fix>m 
the sale of the program, fiiey may be reluctant to release the source code. I would briefly advocate here that 
it is possible to protect a company’s substantial intellectual property investment in the code while still 
providing this fimctionality. Rarely is any serious intellectual investment required for die input and outyut 
routines within the source code and likewise, need not be rendered unavailable. The more sensitive data 
and computational routines could be packaged within libraries and thus protected. 

* For a particularly complex source-code file structure, this can be essential. The codes VIPRE and 
FRAPCON were easily organized and compiled using Visual Fortran. On the other hand RELAP has a 
particularly complex code structure, it was necessary to obtain fi'om a third party a form of the code 
arranged in a Visual Fortran workspace to allow compilation. In die UNIX operating tystem, it is common 
practice in cases where the source code is provided, to also provide standard configuration shell scripts and 
compilation files (such as Makefile and make.inc among ethers) to fecilitate code maintenance and 
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to modify the source code for purposes of constructing new output files that contains only 
the specific data that is sought after. This relieves the designer of the script interface of 
the requirement to develop the logic structure required to parse a general output file for 
the specific data required.*^ 

In the following sub-sections, a description is given of the, generally more limited 
and incomplete, script-interface functionality that has been provided for FRAPCON and 
RELAP, and how it can be used in co-operation witii the script interface created for 
VIPRE. 

Frapcon 

The Matlab-FRAPCON interface is designed in much the same way as tiie Matlab- 
VIPRE Interface. A schematic representation is show in Figure 5. 



Figure 5: Schematic Representation of Matlab-FRAPCON Inter&ce. 

Unlike the interface developed for VIPRE, all of the data required to generate a valid 
input file for FRAPCON is stored in a relatively short script accessed directly by Matlab. 


modificadon. If a script inter&ce were to be created for a code in a variant of die UNIX operating system 
diese files should also be available. 

** I.e. It is difficult in gmieral to separate the numeric data from die accompanying eiqilanatoTy text 
contained in an output file. If on die other hand, the file is only numeric, with die numbers arranged in die 
format dictated by die inter&ce designer, data parsing can be done simply and with much more generality. 
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Scripted Coupling of Codes for Multi-Physics Simulations 

As discussed hitherto in this chapter, when the concept of providing a Matlab-based 
script interface to a code is brought to reality, many benefits are provided in the way of 
parametric analysis and optimi 2 ation. Further benefits can be derived by providing the 
same scripted interface to more than one code. When this is done, the analytical 
capabilities of both codes may be combined in such a way as to improve the applicability 
or fidelity of the analysis. 

As an example of this concept is the Matlab-VIPRE-FRAPCON Interface. A 
schematic representation of this is given in Figure 6. 



Figure 6 : Schematic Representation of tiie Matiab-VIPRE-FRAPCON interface. 

The figure is drawn to suggest that VIPRE and FRAPCON are somehow coupled 
together. This is trae only in the loosest sense. It is the input parameters provided to 
each code and the output values provided by each code that separately coexist in the 
Matlab workspace context. Scripts can be written, that can, for example, look at the 
output of an appropriate FRAPCON analysis and incorporate these results into a VIPRE 
input file for the purposes of improving the accuracy of the VIPRE model. 

An example application of this approach would be for modeling the changes in T/H 
behavior for a very long cycle length (VLCL) core. In particular, for VLCL core designs 
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that are very sensitive to minor perturbations in the fuel geometry. An example of a 
design with these properties is the ERIS Tight core described in section 2.5. 

This is a core where the pitch-to-diameter ratio was designed to be nearly as tight as 
possible. For a fixed fuel rod pitch, even small changes in the rod outside diameter have 
a d ramat ic impact on critical design parameters such as MDNBR, core pressure drop, and 
coolant flow velocity. A demonstration of this sensitivity is given in Figure 7. A 
problem lies in the fact that, for a VLCL core, fuel dimensional changes are very likely to 
occur, and it would be useful to take these changes into accormt in a quantitative way, if 
possible. 


MCMBR «• Rod OunMt DiMMltr 


Cm Prmurt Oroe «t Rod Outsidi OiaiMior 




CoolanI Velocity vs Rod Outside Oiemeler 



F^re 7: IRIS T^ht - Effect of Rod Diameter Variation with Constant Rod Pitch, Linear Power and 

Mass Flux. 

For VLCL cores, physical phenomena occurring witiiin the core such as cladding 
corrosion, fuel swelling, fission product gas release and cladding creep act to change tiie 
rod outside diameter, and therefore impact the T/H conditions in the core. FRAPCON is 
exactly the sort of tool required to quantify the cumulative impact that all of these 
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processes have on the performance of the fuel over the life of the core. The use of an 
integrated script interface to both VIPRE and FRAPCON, allows for automated transfer 
of data resulting from FRAPCON analysis to VIPRE input files to update the T/H model 
to account for the changing fuel conditions. 
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Chapter 3 IRIS Open Core 
Thermal Hydraulic Analysis 


3.1. Introduction 

Thermal hydraulic (T/H) analysis plays a critical role in determining the 
acceptability of any prospective reactor core design. This analysis must be made as an 
integral component of the overall core design effort that will include other important 
analysis such as: 

• Core neutronics design: Is the reactor critical? What is the core reactivity 
lifetime? What is the core power distribution (axial and radial)? Are the 
reactivity coefficients within acceptable limits? 

• Steam Generator (S/G) and balance of plant design: How much surface area does 
the S/G require? What is the minimum S/G tube thickness allowed? What will 
be the flowrate of secondary systems fluids? 

• Containment design: How does one ensure that the containment will not fail in 
the event of a large loss of coolant accident (LOCA)? 

The above list is not exhaustive, but should give a good feel for the context in which 
the T/H analysis must exist. For the core T/H analysis, the main questions are: Can I 
remove the heat generated in the core while maintaining the fuel clad at an accq>table 
temperature during steady state operations? Will the fuel centerline temperature be 
acceptable imder the same conditions? Can I prevent fuel or cladding damage in the 
event of certain foreseeable accidents? How do system design and behavioral 
uncertainties impact the answers to the above questions? 

Not all of these questions are addressed in this chapter. In this chapter, the 
philosophy, methodology and results will be provided for the IRIS Open Core steady 
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state and transient core T/H analysis. The transients to be considered are all specific 
instances of a more genwal category of accident referred to as the Loss of Flow Accident 
(LOFA). In particular die casualties are: 

• Locked-Rotor/Shaft Shear (LRSS): In this accident, one reactor coolant pump 
(RCP) is incapacitated by either the seizure of die pump rotor or loss of 
mechanical integrity of &e pump motor shaft. In either case, the pump loses it’s 
ability to circulate cooling water to the core. 

• Partial LOFA (PLOFA): In this accident 4 of the 8 RCPs stop operating for 
un^)ecified reasons. 

• Complete LOFA (CLOFA): In dds accident, all 8 RCPs stop operating for 
unspecified reasons. 

These accidents will then be analyzed in such a way as to include in the analysis die 
effects of core operational parameter and design uncertainty using three different 
methodologies of vaiying degrees of conservatism. 

3.2. Thermal Design In Practice 

The goal of T/H analysis is to ensure that the core can be safely cooled over die 
design life under normal and accident conditions. This analysis must make provisions for 
the uncertainty inherent in engineering design and construction, as well as uncertainty in 
core thermal performance over the core lifetime. As allowances are maHp for the 
occurrence of operational transients and for uncertainties in and changes of core behavior 
over core life, die allowed core power must be reduced. This is illustrated in Figure 8. 






THERMAL ANALYSIS IN PRACTICE 


Deaga Condidon 


Safety Analsrsis Limit 

Design limit 

Correlation Limit 

Faihire Limit 


In the absence of any uncertainty, the core Power Rating could be set such that the 
MDNBR is at the Failure Limit, defined in this context to be die condition where 
MDNBR=1. 

Unfortunately, the correlations used to determine MDNBR for a known set of core 
conditions is subject to error. To account for this uncertainty, it is required that the 
calculated MDNBR be sufficiently greater than one so that the analyst can have 
reasonable confidence that die actual MDNBR is greater than one.® One way that this 
can be accomplished is, by using the statistical properties of the test data used to 
formulate the DNB correlation, to increase the limit MDNBR by an amount so that there 
is a 95% probability with 95% confidence'’ diat DNB has not occurred. This value is 
termed the Correlation Limit, and Table 5 is a short list of these limits for a few 
correlations. This effect is shown on the left side of Figure 8, and implies a reduction in 
the core Power Rating (shown on the right side of Figure 8). For those correlations listed 
where this Correlation Limit DNBR has not been established: EPRI, Bowring, MacBeth 


* I.e. What does the calculated MDNBR have to be to ensure fliat DNB has not occurred in the core. 

’’ Colloquially referred to as: *^5/95 confidence”. 
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Fi^re 8: Thermal Analysis in Practice. 








and AECL-UO Look-Up Table, a value of 1.30 was used. As shown in Figure 8, the 
Correlation Limit DNBR is given as 1.30. 


Correlation 

Correlation Limit DNBR 

WRB-1 

1.17 

W-3L 

130 

B&W-2 

132 

CE-1 

1.13 


Table 5: Correlation Limit for Some DNB Correlations (Source: reference fll]). 

In a similar fashion, the core as initially designed ha-s properties that are subject to 
imcertainty. Examples include: fuel rod diameter, fuel cladding thickness, fuel 
enrichment, core flow rate, and coolant temperature. Because of these uncertainties, at a 
given power level, portions of the core may be closer to thermal limits than that which is 
computed otherwise. To accoimt for tiiese uncertainties, the allowed Power Rating must 
be reduced and, equivalently, the MDNBR limit must be increased. This is referred to as 
the Design Limit MDNBR. The numerical value of the Design Limit MDNBR is 
assumed to be approximately 1.4 in Figure 8, but the actual numerical value used is 
dependent upon the specific core and the specific CHF correlation being used. 

Over the life of the core, due to material degradation mechani sms or, in the case of 
transition cores, changes are made to core design® from use of mixed fuel assembly 
designs. These changes result in either or botii T/H degradation and an increase in design 
uncertainty that must be further accommodated by lowering the Power Rating, and thus 
increasing the nominal steady state MDNBR For this example an additional 0.15 is 
added to the Design Limit MDNBR to allow for this uncertainty leaving the Safety 
Analysis limit MDNBR at approximately 1.55. 

* More specifically - transitional changes in core design. An example of this would be die gradual upgrade 
of fuel assemblies over several fuel batches. 







Finally, core transient behavior must be taken into consideration. To account for the 
T/H degradation caused by plant operational transients, additional thermal margin must 
be added and the Power Rating reduced. For this example, the value of 2.0 was assumed 
to be sufficient. When all uncertainties and transients are taken into account, the Design 
Condition power and MDNBR is obtained. 

It cannot be overstressed that the exact allowances that must be made to the core 
power limit or MDNBR limit are strictly core (or, fuel assembly) and DNBcorrelation 
dependent. The typical values that are stated in this section are based on a PWR^ using a 
correlation such as W-3L. The results would be completely different, for example, if the 
EPRI correlation were used instead.® 

3.3. Thermal Hydraulic Analysis 
Methodology 

This is a chapter presenting T/H analysis methodology not design or optimization 
results. Nearly all of the design decisions for the IRIS Open Core had been made 
previous to the analysis described here. Core design parameters such as fuel rod 
thickness, fuel rod and assembly pitch, coolant mass flow rate and core thermal power 
have already been determined by IRIS consortium members from around the world. A 
summary of these activities can be found in reference [12]. Given this status, no 
consideration was given to further parametric analysis or optimization studies. The 
design is merely analyzed in its present state. 

The tasks to be completed for this analysis are enumerated in this section. The 
following sections provide a more detailed description of each task. The tasks are: 

• Collect data required to model the IRIS Open Core using an accepted T/H 
analysis code. For this project the subchaimel analysis code named Versatile 
fatemals and Component Program for Reactors: EPRI (VIPRE) was selected. 

• Evaluate core T/H performance at steady state. Ensure that the minimum 
departure from nucleate boiling ratio (MDNBR) is sufficiently high so as to 

** The thermal limits in question (in this case, MDNBR) are not, for example, applicable to a liquid metal, or 
gas cooled reactor. 

* The response of various DNB correlations to changes in linear power is compared in section 3.5 of this 
thesis. In section 3.5, it is shown diat correlations such as EPRI and Bowring, respond much differently to 
changes in linear power than W-3L or B&W-2. 








provide adequate roargin during transient analysis. Also, ensure that fuel clad and 
centerline temperatures are sufficiently low. 

• Develop a set of input data for a plant simulation model. For this project the code 
RELAP was used. This code was used to find macroscopic plant parameters 
during die course of a postulated transient such as: core inlet temperature, system 
pressure, core thermal and neutronics power, and coolant flow rate. This 
information was then used as input data to the VIPRE code for transient 
simulation 

• Perform T/H transient analysis using VIPRE. Ensure diat the lowest MDNBR 
attained during die transient is above the required limits. 

• Perform T/H sensitivity analysis (using VIPRE). Determme the percentage 
change of MDNBR for a given percentage change in a given input variable. This 
analysis provides a key input to the uncert^ty analysis procedure 

• Perform T/H uncertainty analysis. This task is meant to ensure (with a required 
level of confidence) that the core T/H conditions will be acceptable even in the 
presence of design uncertainty. 

The tasks listed above do not rqiresent an exhaustive list of all tasks required for a 
full T/H analysis. Additional analysis would be required for the following: 

• Establish an envelope of safe steady state operations - In principal this envelope 
would determine die initial conditions firom which accident analysis would begin. 
The worst-case initial conditions would represent the initial conditions for a given 
transient^ diat produces the most damaging result. This set of conditions would be 
used for die transient plant simulation. Researchers at Westinghouse have 
initiated transirat analysis indqiendendy using nominal parameters for initial 
plant conditions. 

• Determine the set points for plant protective features. For example this analysis 
would be used to determine at what power level a scram signal should be 
initiated. 

These analyses were considered to be outside the scope of diis work. 

3.4. IRIS Open Core Model Description 

Engineers at Westinghouse Electric Co. Science and Technology Division 
formulated the IRIS Open core model. In so doing, many modeling decisions were made 
based on standard Westinghouse T/H design procedures. The basic model parameters are 
described here. 


^Not all transients would have idoitical ‘Svorst-case" imtial conditions. For some transients such as 
LOCA, hi^ power and high temperature, with an extended ‘thermal history’ of recent long-term high 
power operatitms would represent the worst-case conditions. For some reactivity induced accidents such as 
a sudden rod witiidrawal - low initial power, low temperature would be limiting. 
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The whole core is represented by a 1/8* core section that is consistent with the 
geometrical and physical symmetry present in a typical PWR. The original core called 
for a Westinghouse standard 15x15 fuel assembly design. It was determined during 
steady state and transient core T/H analysis that the 15x15 design was not delivering the 
thermal performance hoped for.® The 17x17 fuel assembly was chosen as an alternative. 
The assembly linear heat rate is the same as for the 15x15, but the per-rod linear heat rate 
is lower simply because there is a larger number of fuel rods in the 17x17 array. Despite 
the smaller rod diameter, the increased total surface area translated into a 6 percent 
reduction in heat flux in the 17x17 fuel rods.®* This was found to be sufficient cause to 
change the 17x17 fuel assembly design. 

Generic parameters were used to account for grid and mixing coefficients, turbulent 
and laminar ftictional coefficients, and correlation selections for various thermal 
hydraulic flow and heat transfer regimes. A detailed discussion of these decisions can be 
found in reference [12] chapter 5. The 1/8* core subchannel nodalization scheme and 
pertinent design information is presented in Figure 9. 


Parameter 

Value 

Core Thermal Power 

1000 MW 

Core Average Linear Heat Rate 

3.04kW/ft 

System Pressure 

15.58 MPa 


(2260 psia) 

Total Core Flow Rate 

36,000 kg/s 


(1.235 Mlbm/ft^-hr) 

Core Average Coolant Inlet 

292 “C 

Temperature 

(557.4 T) 


* The MDNBR was too low. 

The fuel centerline temperature also was considerably lower for the 17x17, though diis is not a limiting 
condition for the accidents considered in this analysis. 
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F^re 9: IRIS Open Core subchannel nodalization and design information 


3.5. Steady State Thermal Hydraulic 
Analysis 

The limiting parameter for the steady state T/H analysis for this core is die MDNBR.‘ 
This parameter requires the use of an empirical correlation. The choice of which 
correlation to use is of critical importance to die validity of the T/H analysis. For this 
analysis, several CHF correlations were used and compared to one another. 

The physical processes that underlie the phenomenon of CHF have been studied 
thoroughly in both theory and experiment. Summaries of diis work can be found in 
references [13]-[17], though die body of literature on this subject is enormous. Despite 
the attention given to CHF, die phenomenon has resisted all efforts at developing a 
predictive model based completely on theoretical ‘first-principles’. The process whereby 

* In a more general diermal hydraulic design, several parameters can potentially be design litniting Some 
common examples include: foel centerline temperature, core pressure drop, coolant velocity and core 
temperature rise. 
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the fluid, flowing along the channel walls is replaced by a blanket of steam bubbles is 
difficult to e7q)lain concisely, and extraordinarily complex to characterize exactly; so 
dependent is it on the exact physical configuration imder consideration. Many natural 
phenomena of interest are like this - as examples: fully developed turbulence and 
reaction chemistryDespite this, we can model some processes quite well because 
they are regulated by higher-level physical laws. For example, the laws of 
thermocfynamics, the laws of plasticity, and the laws of hydrodynamics make meaningful 
simulation possible - though they are built upon the lower-level laws of quantum 
mechanics from wfrich direct simulation would be impossible.^ 

The choice as to which correlation is ‘most acceptable’ is one that must be made 
using the experience and judgment of the analyst. In the final analysis, it must be proven 
by experiment that CHF will occur, for a given fuel assembly design, in a way that is 
accurately described by the CHF correlation that is to be used. Alternatively, and perhaps 
more likely, a new CHF correlation could be developed*' that takes maximum advantage 
of design features of the fuel assembly.' 

The fuel assembly to be used in this core can be most accurately and reliably 
analyzed using the WRB-2 correlation developed by Westinghoiise. This correlation 
takes into account the carefully designed, fabricated and installed support and tnixing 
grids provided for improved heat transfer within the fuel assembly. Additionally, this 
correlation has been extensively tested and validated so as to have proven capability for 
the particular fuel assembly selected. Unfortunately, the WRB-2 correlation is 
proprietary and cannot be used in this analysis. 

As a substitute to the WRB-2, the W-3L, EPRI, Bowring, Babcock & Wilcox-2 
(B&W-2), MacBeth and the Atomic Energy of Canada Ltd - University of Ottawa 
(AECL-UO) Look-up Table are used for comparison. 

^ All students and practitioners in fields requiring comuter simulations should read and memorize reference 
118 ]. 

* Or, more accurately, a slight variation of an existing correlation would be developed. 

' Much effort is erq>ended in die way of improving the thermal performance of the fuel assemblies. This is 
a key activity for a company that is in the business of selling fuel assemblies to nuclear power plant 
operators. The design improvments would be of little use if they were not c^tured by CHF correlations. 
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For the analysis presented in this diesis, the CHF correlations will be of particular 
interest. These correlations, along with their data ranges of are presented in Table 6. 


Correlation 

Pressure 

(psia) 

Mass Flux 

Mlbm /, 

7ft" -hr 

Quality 

Heated 

Length 

(ft) 

Hydraulic 

Diameter 

(in) 

Geometry 

Type 

IRIS Open 

2259.4 

1.235 

_ 

.0.3-0.02” 

14.0 

0.529 

Rod bundles 

B&W-2 

2000 - 4000 

0.754.0 

-0.3-0.2 

6.0 

0.2-0.5 

Rjod bundles 

W-3L 

1460-2460 

1.96-3.68 

-0.15-0.15 

8.0-14.0 

0.2-0.7 

Rod bundles 

MacBeth 

15 - 3000 

0.0073-13.7 


0.08-12 

0.04-1.475 

Round tubes 

Bowring 

90-2250 

0.04-3.0 

_i 

• 

5-15 

0.03-14 

Islet 

subcooling 

EPRI-I 

200 - 2450 

1 

o 

-0J15-0.75 

2.5-15 


PWR^BWR 

(Matrix 

subehannels 

only) 

AECL-UO 

Look-Up" 

(Ref[19]) 

14.5 —2900 

0-5.53 

-0.5-1.0 

See note 

Sec Note 

See Note 

* These values are not available 


Table Data Ranges for Critical Heat Flux Correlations (Reference (2]). 


Direct comparison of different CHF correlations is a subtle and perhaps 
unappreciated business. Figure 10 is provided as an illustration of this complexity. At 
the nominal design power of 3.04 kW /^, the MDNBR, as determined by die six 


“ Corresponds to inlet and outlet equilibrium quality for nominal steady-state conditions. 

* The AECL-UO Look-Up table uses correction &ctors to take into account die effect of heated length, 
hydraulic diameter and the geometty type - a bundle correction fector is used. 
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different correlations, ranges from the lowest: EPRI — MDNBR = 1.667, to the highest: 
MacBeth - MDNBR=5.078. Because of the significant disagreement of the MacBeth 
correlation with all others presented, the MacBetb correlation will not be used when 
considering the T/H acceptability of the IRIS core. It will continue to be considered, 
however, in interest in observing the behavior of this correlation in comparison to the 
others. 


MDNBR vs Power 



F^re 10: Comparison of Various CHF Correlations for IRIS Open Core. Cosine 

Power Shape, peak = 1.55. 

While a broad range of MDNBRs is indicated for the core at nominal power, the 
powers for which the correlations predict the occurrence of CHF are relatively closely 
spaced. This illustrates the difference between DNBR, as a ratio of local heat flux to that 
which would cause CHF, and the Critical Power Ratio (CPR) which is the ratio of the 
total power (includes chaimel power history) to that which would cause CHF. Based on 
the nominal power, the CPR for the six correlations is provided in Table 7 and a plot of 
MDNBR versus CPR is given in Figure 11. It should be noted, that this analysis does not 
take into consideration any inaccuracy in the CHF correlation itself. 
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Correlation 

MDNBR at Nominal 
Linear Power of 

3.04(*y^) 

Linear Power for 
MDNBR =1.0 

(*%) 

CPR at 

Nominal linear power of 

3.04 (*%) 

EPRI 

1.692 

4.734 

1.577 

AECL-UO 

2.111 

4.336 

1.445 

ESSSSSi 

1.843 

4.844 

1.615 

B&W-2 

3.631 

4.340 

1.447 

W-3L 

2.433 

4.518 

1.506 

MacBeth 

5.179 

5.908 

1.969 



CPR 

Figure 11: IRIS Open MDNBRvs CPR 

The range of CPRs given in column 3 of Table 7 is much less wide than the 
MDNBRs provided in the first column of the same table. This is illustrative of the 
common misinterpretation of the reported DNBR as a measure of power margin at 
conditions less than the critical condition. For example, given only the DNBR, one could 
then assume that, while the EPRI correlation indicates only a modest margin to tiiermal 
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limits witii wiiich to absorb the effects of uncertainties and transients, the W-3L is much 
more optimistic and predicts more margin. The CPR analysis indicates that the two 
correlations make relatively similar predictions (ignoring uncertainties) concerning the 
power at which CHF will occur. 


The reason for this behavior has its roots in die formulation of the different CHF 
correlations and is discussed in detail in reference [16]. Correlations such as EPRI and 
Bowring, have the ffinctional form of: 


Equation 9 


Qchf ~ f\ 




or- 


9" JJ 


Where: 

9chf ^Computed Critical Heat Flux 

G = Mass Flux 

Xin = Inlet Quality 

hin = Inlet Enthalpy 

p = pressure 

Dh =Hydraulic diameter 

z =Axial height 

For these correlations, the local quality is eliminated by incorporating the heat 
balance along die channel up to the point z of interest. For diis reason, these correlations 
result in a computed CHF that is fairly constant despite changes in core power. This is 
manifested in Figure 11 as a line with a slope equal to negative one. Correlations such as 
W-3L and B&W-2 use only local channel conditions to determine the value of CHF and 
are of the form: 


Equation 10 

qcHF = ) or, if heated length, L, is taken into account: 

^CHF ~ P) ’ •^) 


For correlations such as tiiese, computed CHF increases when chaimel power 
decreases, causing MDNBR to increase faster than CPR when linear power is reduced. 
This is manifested as a more negative slope in Figure 11 as is shown. In this thesis, as 
will be pursued further in the Sensitivity Analysis section, the different responses of a 
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DNB correlation to increases in power will be manifest as an increase in power 
sensitivity. 


3.6. Transient Thermal Hydraulic Analysis 

The steady state thermal hydraulic analysis is a valuable tool in many senses, hut for 
the purposes of fully determining die T/H acceptability of a core design, transient 
analysis is crucial. Reactor licensing rules require that the plant be able to undergo all 
Condition I and Condition II transients without sustaining fuel damage. The definitions 
of these transients are^®^; 

• Condition I: These occurrences are operations that are expected fi'equently or 
regularly in die course of power operation, refueling, maintenanc e, or 
maneuvering of the plant; they shall be accommodated with margin between any 
plant parameter and the value of that parameter which would require either 
automatic or manual protective action. 

• Condition II: These occurrences include incidents, saay one of which may occur 
during a calendar year for a particular plant—examples include inadvertent 
control rod withdrawal and loss of a single reactor coolant pump. Condition II 
incidents shall be accommodated widi, at most, a shutdown of &e reactor with the 
plant capable of returning to operation after corrective action; any release of 
radioactivity shall be in conformance with paragraph 20.1 of 10CFR20. 

The modeling and simulation of these transients is a task of significant magnitude. 
For diis task, the plant simulation code RELAP was used. This code combines tiie 
detailed hydraulic and heat transfer charactmstics of the entire reactor plant" alo ng with 
the neutron kinetic behavior of the nuclear core. This analysis benefited greatly from the 
contribution of IRIS Consortium partners worldwide who created the RELAP model of 
the IRIS reactor plant. 

While the RELAP code incorporates physical models of sufficient detail to provide 
reasonable fidelity with regard to macroscopic system behavior, the code in and of itself 
is not endowed witii the models required to determine the detailed T/H conditions within 
the core. In particular no determination of the proximity to CHF is made. This task is 
relegated to VIPRE. RELAP does, however, provide the necessary time'dependent data 
for: 


° Including the Steam Generating system and BOP. 
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• Average core inlet temperature 

• System pressure 

• Core thermal power 

• Core coolant mass flow rate 

This information is then provided to VIPRE for the purposes of the transient T/H 
calculation. 

Complete Loss of Flow Accident 

The CLOFA was modeled with the IRIS RELAP model, providing input to VIPRE 
as previously discussed. The general transient consisted of all 8 RCPs simultaneously 
losing power, followed 1.5 seconds later by a full reactor SCRAM. The time-dependent 
behavior of the plant during the CLOFA transient as computed by RELAP is shown in 
Figure 12. 




557.7 



10 20 
Time (sec) 


F^re 12: IRIS OPEN CLOFA transient profile. 


Using the inputs provided by RELAP,’’ DNBR was computed for all modeled 
chaimels, for all time steps using the W-3L, Bowring, EPRI, B&W-2 and Macbeth 


** The RELAP results used in this analysis are preliminary in nature. The RELAP model of tihe IRIS Open 
eore is subject to nearly continuous revision and improvement Since the focus of this work is both 
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correlations. The W-3L correlation exhibited poor performance as mass flux decreased. 
This is not surprising, as the low mass-flux is outside the range of applicability for the W 
3L correlation. The CLOFA was modeled with tiiree cases corresponding to possible 
coast down rates of the RCPs. The results of running VIPRE with the RELAP data for 
tire nominal case are provided in Figure 13. 



Figure 13: Nominal Conditions. 

The coast-down rates are characterized by the term p which has dimensions 
(1/second) and is used in the following equation describing pump RPM as a function of 
time following pump trip: 

^ > where: 

V + P'f) 

Q(t) is pump speed as a function of time. 

methodology and results, and because some version of the RELAP results had to be used (as opposed to 
ccmtinually repeating the calculations as each improvement in die RELAP model is implemented diese 
RELAP results are considoed adequate for this anab'sis. 











Qo is the initial pump speed 

and t is time from pump trip, in seconds. 

If P is given a large magnitude, die model of the pump will indicate faster coast- 
down. The reverse is true if p is smaller. The nominal value of P is 0.33, the values of 
0.21 and 0.5 were chosen as a reasonable upper and lower bound. The VIPRE-generated 
results for both cases are provided in Figure 14 and Figure 15. 


CLOFAMDNBR-p = 0.21 



Figure 14: Slow Coast Down 
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CLOFAMDNBR-p = 0.50 



Figure 15:Fast Coast-Down 


More recent analysis has demonstrated that p can be expected to be 
significantly lower than 0.33. (reference [21]) 


Partial Loss of Flow Accident 4 of 8 Reactor Coolant Pumps 

This casualty was modeled in a similar manner to the CLOFA with the exception 
that only 4 of the 8 RCPs were halted for die transient. The reactor receives a Loop Low 
Flow trip signal when flow reaches 87% of nominal which occurs approximately 0.9 
seconds into the transient. The time-dependent behavior of die plant during the PLOFA 
transient as computed by RELAP is provided in Figure 16. 
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Figure 16: HUS OPEN PLOFA Transient Profile. 

The VIPRE results obtained for the 17x17 core for the transient conditions of Figure 
16 are presented in Figure 17. 
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LOFA 4 of 8 MDNBR • Nominal Conditions 



Figure 17: Partial Loss of Flow Accident 4 of 8 Nominal Conditions. 

One might notice from this result that, after approximately 3.5 seconds, the 
MacBeth, B&W-2, and W-3L correlation MDNBRs become steady at a value of 10. This 
is a result of the way that VBPRE reports DNBR values. If a correlation predicts a DNBR 
greater than 10, the code simply returns the value 10. If the correlation predicts, due to 
die numeric behavior of die DNB correlation a negative value of DNBR,^ then the code 
simply prints out a warning to indicate such a condition. 

Locked Rotor/Shaft Shear 

This transient was modeled in a similar fashion as the PLOT A, but in this case only 
one pump was stopped. The time-dependent behavior of the plant during die LR/SS 
casualty is illustrated in Figure 18. 


^ This condition often occurs with the W-3L correlation for conditions of low mass fhix. Communication 
with Westinghouse Scientists indicate that this behavior is typical of Westinghouse Correlations. 
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F^re 18: IRIS OPEN LR/SS Transient Profile. 

The results for the 17x17 case are provided in Figure 19. 


LRSS MDNBR - Nominal Conditions 



Figure 19: LR/SS transient results - nominal conditions. 

















In summary, for plant initially at nominal conditions, the MDNBR results for die 
preceding transients are provided in Table 8. 



MacBeth 

B&W-2 

W-3L 

Bowring 

EPRl 

AECL- 

UO 

LR/SS 

4.588 

2.974 

2.180 

1.578 

1.495 

1.763 

PLOFA 

1 

4.753 

3.055 

2.238 

1.589 

1.516 

1.848 

CLOFA" 

4.308 

1.527 

1.993 i 

1.276 

1.296 

1.828 


Table 8: Snmmary of Nominal Condition Transient Results. 


3.7. Sensitivity Anaiysis 

After having completed die steady state and transient analysis with the core initial 
conditions set to dieir nominal values, it is desirable to know quantitatively the impact on 
MDNBR dial should be eiqiected for a given perturbation in the plant conditions. For the 
purposes of thermal hydraulic analysis, knowing this relationship provides relevant 
insight not only of plant behavior, but also of the relative behavior of various CHF 
correlations. 

The knowledge gained in the sensitivity analysis is of critical importance for 
performing uncertainty analysis. The various mediods employed for uncertainty analysis 
will be discussed in detail in the next section. One procedure, the Westinghouse 
Improved Thermal Design Procedure (ITDP), >^ch is given a detailed treatment in 
reference [22], uses sensitivity factors as the centerpiece of the uncertainty analysis. 

Even if one is not using the ITDP as their main uncertainty analysis mediodology, the 
sensitivity analysis can give quantitative indications of which plant parameter contributes 
most to imcertainty in the MDNBR for any given set of conditions. This can then 


' Only base-case b considered here. 
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indicate to plant designers ways in A^ch overall plant uncertainty can most economically 
be reduced, leading to improved plant thermal margins. 

The sensitivity is dependent upon both the parameter under consideration and the 
DNB correlation in use. Sensitivities were obtained for Inlet Temperature, System 
Pressure, Mass Flux, Linear Power, and Engineering Enthalpy Rise Hot Channel Factor® 
(F^) for the W-3L, B&W-2, MacBeth, Bowring, EPRI and AECL-UO Look-up Table 
DNB correlations using two different methodologies. 

For the first procedure, ten data points were chosen over a selected range of interest 
for each parameter. The range for each parameter is shown in Table 9 as the ‘Minimum’ 
and ‘Maximum’ value for each parameter. At the ten data points within this range, ten 
steady state VIPRE runs were conducted with the parameter of interest varied over a ± 

1% range about the given data point.* All other parameters were maintained constant, 
and at their no minal value. Using the MDNBR data firom each steady-state simulation, 
sensitivity was computed with the units of ‘percent-per-percent’. (i.e. percent change in 
MDNBR divided by percent change in parameter) 


‘ The definition of the Engineering Enthalpy Rise Hot Channel Factor is given as: 
pE _ Enthalpy 

^ AEnthalpy^„_^^g, 

* A total of 100 VIPRE runs is therefore made for each of the five parameters (500 runs), for each CHF 
correlation (6 correlations for a total of3000 VIPRE runs). The Matlab-VIPRE Interfece was used for this 
analysis that would otherwise have taken several days of intensive effort if performed "by hand’. Rather, 
these analysis were scripted and run during a single evening on a personal computer that was otherwise 
unused during this time. 
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Parameter 

Minimum Value 

Nominal Value 

Maximum Value 

Inlet Temperature 

500 °F 

557.6 ®F 

580 “F 

Mass Flux 


1753 

n^-hr 

, f. MLbm 

J. ^ 

fi^-hr 

System Pressure 

2150 psia 

2259.4 psia 

2375 psia 

Linear Power 

2.6^ 

n 

3.04^ 

ft 

3.5^ 

ft 


1.0 

1.02 

1.04 


Table 9; Range of analysis for sensitivity study. 


The sensitivity plots for this procedure are provided over the next several figures." 
The nonunal value of each parameter is marked with a cross-hatched line on each plot. 


An example scrip* used to generate these uncertainties is provided in the appendices. 
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Figure 20: Parameter Sensitivities 


It is notable that the sensitivity of most of the correlations is increased as the 
parameter is moved ‘closer’ to the DNBR limit - for example, as inlet temperature is 
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increased, the temperature sensitivity in increased. This has been foimd to be a feature 
common among the correlations studied in this sensitivity analysis. Also interesting to 
note is the difference in sensitivity between different CHF correlations. For example, the 
sensitivity of B&W-2 to all parameters is ‘stronger’ than for W-3L. This observation can 
be linked to the fact that, in Figure 10, the B&W-2 correlation has a steeper slope than 
the W-3L correlation. This indicates that the B&W-2 has, in general higher power 
sensitivity than tiie W-3L correlation. Without calculation one would guess that B&W-2 
then also has higher power sensitivity than all of the other correlations considered. 
Numerical results will show that this is in-fact the case. 

The above observation led to the second sensitivity analysis methodology that was 
employed for this study. The problem lies in the fact that, as will be shown in the 
Uncertainty Analysis section, for the ITDP, a single sensitivity factor must be selected, 
though it is clear from the previous figures that none of the sensitivities are constant If a 
sensitivity factor is chosen that is too small, then the analysis is non-conservative.^ If a 
sensitivity factor is chosen that is too large, tiien the analysis is over-conservative, 
resulting in a loss of power margin. Clearly, appropriate choice of the sensitivity factors 
is an important step in the ITDP that will be subject to close scrutiny from both regulators 
and potential customers. It may seem to be over-conservative to simp ly choose the 
largest sensitivity factor within the range considered for use in the ITDP since the range 
considered is quite broad compared to the range of parameters anticipated during plant 
operation. It is quite unlikely that any of the parameters considered would be so far from 
their nominal value. On the other hand, it would seem arbitrary to pick any value other 
than the highest achieved sensitivity - who decides what value should be chosen? 

The question to ask is: If the sensitivity is increased, as tiie plant is closer to DNB, 
then couldn’t the inlet temperature sensitivity be increased if tiie mass flux was reduced? 
(As opposed to increasing only inlet temperature - since reducin g the mass flux brings 
the core even ‘closer’ to DNB and thus, one could eiqiect the sensitivity of the correlation 


'' As will be shown, a lower sensitivity would dien result in a lower variance for the DNBR - which would 
be a random variable fw die ITDP anatysis. The lower variance is non-conservative as compared to a 
higher variance. 
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to increase) To test for this behavior a second methodology was used. A tighter range 
was selected for each parameter. This range is given in Table 10.'*' 


Parameter 

Range of Interest 

Inlet Temperature 


Mass Flux 

+ 5% 

Linear Power 

±2% 

System Pressure 

± 30 psia 


1.02 ±.02 


Table 10: Parameter ranges for combinatorial sensitivity analysis procedure. 

Three points were chosen in this range for each parameter. The sensitivity was 
found for each parameter for every combination of parameters.* The procedure was 
repeated for all CHF correlations. While this study requires an enormous number of 
VIPRE runs, the task was scripted^ using the Matlab-VIPRE Interface described in 
chapter 2. Aside from the task of writing die script specifying the operations to be 


This is the same range that is used for the Monte Carlo uncertainty analysis procedure. 

* Ibere are 5 parameters, each that are sampled at three points within the range of interest. Hiere are 3^ 
permutations of parameter values. At each permutation, 3 VIPRE runs are performed to find the 
sensitivity. This process must be repeated for each of the 5 parameters, for each of the 6 CHF correlations 

considered for a total of 3* x 3x5x6 = 21,870 VPREruns. To paform this by manually adjusting the 
VIPRE input file, executing VIPRE, and extracting the resulting data would require roughly 200 man-hours 
of work ^t would translate into a nearly insurmoimtable obstacle for fire lone graduate student. By 
contrast, using the scripted interfiice, this calculation could be performed in roughly one day with die 
computer. 

^ Example script included in die sqipendices. 



















performed, the analysis was completed automatically. The results are presented in the 
form of a histogram for each parameter studied. 

Since the data generated from this analysis is rightly placed in five dimensions (since 
there are S uncertain parameters), it was impossible to present the data in a surface or 
volume plot. A histogram was chosen to display this data in order to give die user a 
better feel for the behavior of a parameter’s sensitivity aroimd its nominal value.* In 
most cases, as shown by the histograms, the sensitivity is very close to that which would 
be achieved 'mth all parameters at their nominal values. (The correlation sensitivity 
taken i^hen all parameters are at their nominal value is shown as a cross-hatched line in 
each plot.) On the other hand, there are some combinations of plant conditions diat leads 
to a sensitivity diat is significantly hi^er. It is interesting diat sensitivities can nearly 
double in magnitude even though plant conditions are all still close to nominal value. 


^ Thought this method of presentation is disadvantaged in that it does not show what position widiin the 
parameter space result in particular values of sensitivity. 
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Wet Temperature Sensitivity (%/%) Linear Power Sensitivity (%/%) 
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#OfOccurances #ofOccurances #ofOccurances 


Bowling Inlet Temperature SensWvlty At OtTNominal Conditions Bowring Linear Power Sensitivtty At Ofr«NomlnaI Conditions 




Bowring Mass Flux Sensitivity At Otr-Nominai Conditions Bowring System Pressure Sensitivity At Oir-Nominal Conditions 




Bowring SensWyit/At OIT-Nominal Conditions 



Figure 23: Bowring Correlation sensitivities. 
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AECL-UO MetTempenture SensttivKy At OfT-Nominal Conditions 













































































































































The numerical values of the maximum sensitivity found using this procedure are 
summarized in Table 11. 


Sfinsitivitv ^ ^/n^DNBR/ 
aensraviiy, 5, /Vo^parameter 


Parameter 

EPRI 

Bowring 

B&W-2 

W-3L 

MacBeth AECL-UO 

Mass Flux 

0.81906 

1.0794 

1.481 

0.778 

0.69928 

1.6833 

Linear Power 

1.0623 

1.0808 

2.32 

1.601 

1.2233 

2.5673 

Inlet Temperature 

2.7596 

3.1025 

7.5 

3.65 

3.7275 

7.8802 

System Pressure 

0.39185 

0.25114 

0.84 

0.777 

1.361 

1.6405 


1.0377 

1.2148 

1.8151 

0.595 

0.98569 

1.5670 


Table 11: Maximum Sensitivity. 


As can be seen, the parameter sensitivities vary significantly from parameter to 
parameter and from correlation to correlation. Analysis of the inputs provided in 
generating the above histograms reveals that in every case, the maximum sensitivity was 
found with plant conditions that place the core closest to CHF - low: mass flux and 
system pressure, high: linear power, inlet temperature, and engineering enthalpy rise hot 
channel factor. 

3.8. Uncertainty Analysis 

Uncertainty is present in most every engineering design. For nuclear reactor designs, 
this uncertainty must be dealt with in such a way as to provide ‘acceptable’ confidence 
that the core will, in reality, operate in a manner that is farther from thermal limits than 
that vdiich is predicted from numerical computations. The meaning of ‘acceptable’ has 
changed over the decades. In the nearly 50 years of commercial reactor design 
ejqjerience, there has been a steady evolution of methodologies for conservatively 
handling uncertainty. The methodologies listed in tihls section are not intended to be 
exhaustive, nor do I claim that they are representative of every scheme that has ever been 
formulated. This sampling does however touch over the extreme ends of the continuum 
and I think captures the upper and lower boxmds of conservatism. A general overview of 
these design practices is provided in chapter 8 of reference [23]. 
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standard Thermal Design Procedure 

The Standard Thermal Design Procedure (STDP) is one of tiie earliest techniques 
employed to handle uncertainty. This mediodology is sometimes referred to as tiie 
Cumulative or Product Cumulative eq>proach. Each design parameter subject to 
uncertainty is assumed to be simultaneously at its worst possible value from a DNB 
perspective. In fliis way tiie analyst can ‘guarantee’ that the actual in-core conditions are 
no worse than those postulated in the STDP methodology, and hence, the results obtained 
are, within tiie analytical assumptions made, conservative. The parameters under 
consideration and their worst-case values have already been presented in Table 9.“ For 
the STDP, the transient is simulated under these conditions, and the MDNBR obtained is 
compared to the DNBR limit for the given DNB correlation. 

Locked Rotor/Shaft Shear 

The results of the analysis of the LR/SS transient using the STDP are presented here: 


LRSS MDNBR - STDP Conditions 



Figure 27; 17 x 17 Core, LR/SS Standard Thermal Design Procedure 


** Note diat only process parameter uncertainties and engineering uncertainties are included as an 
illustration of fbe methodology. 
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Partial Loss of Flow - 4 of 8 


The results of the PLOFA transient iising the STOP are presented here: 


L0FA4 of8 MDNBR - STOP Conditions 



Figure 28:17x17 PLOFA 4 of 8 STDP. 


Complete Loss of Flow 


The results of the CLOFA transient using the STDP are presented here 
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CLOFA MDNBR - STOP Conditions 



Figure 29:17x17 CLOFA STDP. 

A summary of MDNBR transient results using the STDP is provided in Table 12. 



MacBeth 

B&W-2 

W-3L 

Bowring 

EPRI 

AECL- 

UO 

LRSS 

4.069 

2.249 

1.961 

1.363 

1.417 

1.711 

PLOFA 

4.243 

2.350 

2.021 

1.360 

1.333 

1.817 

CLOFA 

3.868 

0.356 

1.183 

1.2 

1.157 

1.468 


Table 12: Summary of STDP Transient Results. 


Notice that every correlation except for MacBeth and AECL-UO Look-up Table 
result in a MDNBR of less than 1.30 for the CLOFA transient using the STDP. 


Improved Thermal Design Procedure 

This procedure is discussed in detail in reference [22]. The assumption fundamental 
to this methodology is that the uncertainties for all design parameters are mutually 
independent. Instead of assuming all parameters are at their worst-case value 
simultaneously, it is assumed that each parameter is an independent random variable. 
The DNBR, that is a function of Aese parameters, is therefore a random variable itself, 
with statistical properties related to the uncertain parameters. The goal of this procedure 
is to define a new MDNBR Limit that takes into account the parameter variability, and 





























tibe sensitivity of the correlation MDNBR to variations in each parameter and provides 
95/95 confidence that DNB is not reached wiien the MDNBR for the transient is above 
this limit. 

A parameter ‘y’ is defined to be the DNBR uncertainty factor in the following 
manner: 

Equation 11 

^ Z)jVgR(variable) 

^ D/VBR(nominal) 


The denominator of Equation 11 refers to the DNBR calculated, for the DNB 
correlation of interest, for the core as modeled with all uncertain parameters at their 
nominal, best-guess values. The numerator refers to the value of DNBR as affected by 
the randomly varying uncertain parameters. No assumptions are made regarding the 
exact distribution of these random variables, only that they posses a finite mean value (p), 
and a variance (o^). This uncertamty factor, y, can be formally related to changes in 
design parameters, {xi,...,x„}, and sensitivities, {5i,...,5„}, as follows: 


Equation 12 


y 



+ $2 


dx^ 

^2 



The sensitivity terms are defined to be the percent change in DNBR per percent 
change in the uncertain variable n. The design parameters {xj,..., } are defined to be 

those core design parameters that are subject to uncertainty, and have an impact on the 
core DNBR. If all but the i’th uncertain parameter is taken to be constant, the Equation 2 
can be simplified as below where each represents a design parameter subject to 
uncertainty: 


Equation 13 


y 



or s^ 


y dXi 


of 151 







If all of the uncertain parameters were at their nominal value, by inspection of 
Equation 11, one can see that flie value of y is unity. What we are interested in is the 
behavior of y when all of tiie uncertam parameters are at some perturbation from their 
nominal condition. To analyze this behavior, we will start by formally expanding y in a 
Taylor series about its mean value**: 

Equation 14 

y = -^(^1 - a) +^(^2 - /fs)+• ••+- /^n) + ^gher Order terms 


The required result for the ITDP is an expression that gives Hy and cr^, as a 

function ofthe mean and variance ofthe uncertain parameters Beforethis 

calculation is made, some manipulations and simplifying assumptions are required. 

First, multiply and divide both sides of Equation 4 by . Multiply and divide 

each term on tiie right-hand-side of Equation 4 (with the exception of the ) by tiie 

respective mean value of each random variable. We make the standard assumption that, 
for this expansion, the deviations from the mean value will be small, and therefore the 
higher order twms will be of small ms^tude and can therefore be ignored. The result 


Equation 15 

yMy) {/iyj ^^y Ml ^2 My M 2 My Mn 

^My Ml ^2 My M 2 ^„My Mn 


We wUl assume that y(x,,..., ) is a continuous fimction of the uncertain design variables vdth 
continuous derivatives as required for Taylor Series expansions. 
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Notice now that, on the right hand side of Equation 15, with the exception of the first 

dy u 

term, each other term has the component. This mathematically describes the 

My 

sensitivity that was introduced in Equation 13, but evaluated with both y and the i’th 
uncertain parameter, x, at its nominal (mean) value. Unfortunately, we have no way to 

analytically obtain the partial derivative of y with respect to file uncertain parameters x^. 
While it is true that it is possible to uniquely map a given set of uncertain parameters 
{x,.. } to a specific value of y, fiiis mapping can only be obtained with the use of a 

detailed plant model and thermal-hydraulic analysis code (VIPRE) - there is no way to 
simply write down fiie function y, much less find it’s partial derivatives. As an 
approximation, this quantity will be replaced by the numerically computed sensitivity,*® 
Strictly speaking this is, of course, wrong,*’^ but this converts Equation 15 into a linear 
algebraic function of the random variables {x,,..., x„}. The result now is: 

Equation 16 

Mi fh Mn 

For this equation, since {//j,.and {5j,...,.$„}are assumed to be known and 
constant and fi^ is by construction unity, all of the terms on the right hand side of 
Equation 16 are known. The desired quantity, namely, , can now be obtained directly 

as Equation 17 based on standard results pertaining to the variance of linear functions of 
random variables^^^^’^^^^: 


Equation 17 


2 2 
MySt 




Mi 


+ MySl 


Ml 






<Mn 


The details of die computation of the sensitivities are provided in the preceding section “Sensitivity 
Analysis”. An example of the computer code used for to purpose is provided in the ^pendices. 

other words, the sensitivity is not constant - it is not independent of die value of it’s associated 
uncertain parameter, nor is it independent of the other uncertain parameters as was demonstrated in the 
previously descnbed saisitivity analysis. 
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Now dividing flirough by , we obtain: 


Equation 18 


frr ^ 


2 


2 


UJ 

UJ 

+ 1^2 


+... + 5 ^ 

UJ 


This is the main result of the ITDP, Each s^ is the sensitivity for the i’th parameter 
for the ^ven DNB correlation, and o’, /is the coefficient of variation (COV) for the 
design parameter. 

To employ this procedure, all that is needed are the parameters called for in die right 
hand side of Equation 18. Since is, by construction, unity. Equation 18 can be used 

to solve for <Ty under the combined influence of each random design parameter. 

Since we have not made any reference to the actual underlying distribution of each 
of the uncertain design parameters, it is a legitimate argument to question the underlying 
distribution of the parameter y . There is a well-established, commonly studied, body of 
madiematical results in the case that all of the uncertain parameters are normally 
distributed. In the more general case, vhere die uncertain design parameters are of 
arbitrary distribution, we will assume, based on the Central Limit Theorem,*^^^ that y is 
normally distributed. 

Using this variance, and die assumption that y is normally distributed, the iqiper 95 
% confidence is determined by reducing 1.645 standard deviations. Using the 
notation of reference [22], this gives a factor 0 < < 1 .** 


Equation 19 

F„ =;/^-1.645 o-^=l-1.645 t7^ 

“ Strictly speaking, equation 9 only ensures fliat F„ < 1 since ffy is non-negative for any probabUhy 
distribution. It is not considered plausible that parameter sensitivities would be such that 0'y> 1 .65 so that 
would be negative. 






The correlation DNBR is then divided by this factor, resulting in tiie ITDP limit 
DNBR. 


Equation 20 


DNBRjjj)p — 


DNBR 


correlation-hmit 


The ITDP was employed in the following analysis of each casualty event The W-3L, 
B&W-2, EPRI, AECL-UO and MacBeth correlations were used. The preliminary inputs 
necessary for this analysis are: 

• DNBR sensitivities for each correlation {s, • • • }; 

• The MDNBR for each transient for design parameters at their nominal value 

W; and 

• The postulated probability density fimction for the design parameters of interest 
and their associated statistical properties. 

For illustration each design parameter was assumed to have a rectangular distribution 
(uniform probability) about it’s nominal value. For a rectangular distribution, the 
variance is given by^®^: 

Equation 21 

jb-af 

12 

Here, b and a are the distribution upper and lower bounds respectively. The 
numerical values of the statistical properties of these distributions are provided in Table 
13. 
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Parameter 

Mean Value 

Range of 
Interest*^ 

-? 

cov 

Inlet Temperature 

557.6 T 

±4®F 

5.33 

0.00414 

Mass Flux 

1 235 Mlbm /, 

/ft^-hr 

±5% 

0.00127 

0.0289 

Linear Power 

3.04 

±2% 

0.00123 

0.0115 

System Pressure 

2259.4 psia 

± 30 psia 

300 

0.0077 


1.02 

±.02 

0.000133 

_i 

0.0113 


Table 13: CoefBdent of Variation for Varions Parameters. 


For this analysis, the sensitivity factors obtained from the combinatorial sensitivity 
analysis method described in the previous section were used. These values are provided 
in Table 11. The resulting ITDP DNBR limits for the correlations used are presented in 
Table 14. 


Correlation 

Fu (Equation 19) 

DNBRitdp (Equation 20) 

EPRl 

0.941 

1.382 

Bowring 

0.926 

1.404 

B&W-2 

0.883 

1.495 

W-3L 

0.944 

1.377 

MacBeth 

0.940 

1.382 

AECL-UO Look-up Table 

0.959 

1.355 


Table 14: ITDP DNBR Limits. 

Putting this analysis into the same context as illustrated in Figure 8, an example is 
made of die W-3L correlation as shown in Figure 30. Here, the Design Condition and 
Safety Analysis Limit are yet to be determined, but the Correlation and Design Limit has 
been computed using Equation 19 and Equation 20 account for both correlation 
uncertainties, process parameters and engineering tmcertainties. 


^ Based on recommendations given in reference [22]. 
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THERMAL DESIGN IN PRACTICE 
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Figure 30: Illustration of Effect of Uncertainties for the W-3L Correlation. 

It could be somewhat misleading to compare die ITDP DNBR limits from two 
different correlations. A higher ITDP DNBR limit is reflective of the higher sensitivity 
of a given correlation.®® However, for correlations of equal predictive capability, it 
would be, for tihe purposes of the ITDP, advantageous to have a correlation that exhibits 
the lowest possible sensitivity, therefore resulting in a lower DNBR limit.** 

A second note that should be made regarding the ITDP is the probability distribution 
used to describe the input parameter uncertainty. The ITDP uses only the mean and 
variance of the given distribution, but these two parameters do not represent all of the 
information contained within the statistical distribution. The rectangular distribution is 
parameterized by its computed parameters, but a normal distribution, for example, with 
the same parameters does not mathematically express tiie same meaning with respect to 


** I.e. the DNBR sensitivities {-Si * *' } tend to be larger in magnitude. 

In practice this should not be a problem. T/H analysts in industry do not select from a stable of candidate 
correlations for a given fuel assembly. Instead, a proprietary in-house correlation drat is finely tailored to 
the target fuel assembly is employed. The sensitivity characteristics of the conrelation are b^ond the 
control of die analyst. The point is only made that, ^ other filings being equal, a very sensitive correlation 
- in particular, a correlation that has a widely varying (and large magnitude) sensitivity in many parameters 
will be penalized by the ITDP because of that sensitivity. 
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the parameter uncertainty. The ITDP however does not capture this difference. The 
agnificance of this difference will be demonstrated using the Monte Carlo Uncertainty 
Procedxire where it will be shown that a Afferent (less conservative) answer is obtained 
when using, as an example, a normal distribution with the same mean and variance as 
tiiose of the rectangular distribution. 

Monte Carlo Uncertainty Procedure 

The Monte Carlo Uncertainty Procedure (MCUP) is conceptually much simpler than 
the ITDP. For this procedure, each probability distribution that describes tiie uncertain 
input parameters is sampled a large number of times - typically on tiie order of two to 
three tiiousand samples. These samples are tiien used as trial inputs to the VIPRE 
transient calculation." The resulting MDNBR calculations from all trial inputs are then 
analyzed for their statistical properties. We assume for this analysis tiiat the resulting 
MDNBRs are normally distributed. This can be argued from the tenets of the Central 
Limit Theorem, on plausibility grounds by inspecting a histogram of the outi)ut data, or 
by performing a test of normality - all of which will be done here. The distribution 
parameters of tiie output are then adjusted to achieve the same 95/95 confidence interval 
obtained for the ITDP. 

The core model used for this procedure is exactly the same as that used for the ITDP 
and STDP. This is in contrast to many of the other Monte Carlo-type procedures where a 
simplified core model is used.^^^^ Additionally, the output used to create the MDNBR 
statistics was generated directly from VIPRE. Many other Monte Carlo-type procedures 
use various methods for developing a response surface. In tiiose other methods, such a 
response surface b in turn used to estimate tiie MDNBR that VIPRE would have 
computed for the given input parameters.*^’^ The reqxinse surface they used is then 
carefully and thoroughly benchmarked against a frill VIPRE simulation, but b an 
approximation nonetheless. 

" The transient boundary condition data produced from RELAP is provided in a nonnalized form. 
Therefore, irrespective of die magnitude of inhiai core power, mass flow rate, pressure, or temperature, the 
di^ies of the individual parameters will be the same through die transient This assumption is justified by 
the relatively small perturbations made to the ii^ut data. If^ for example, inlet temperature were 50 percent 
Iowa- before the transient, it would probably be a poor choice to assume that the overall time-t«nperature 
profile is die same as that for die nominal case. 
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As a result of using the methodology as described, die computational requirements 
are not inconsiderable. For the desktop PC used for the majority of numeric 
computations presented in this report, approximately 1 day was required for every 1400 
tr ansi ent simulations. Some consideration was put into how many simulations should be 
run for each transi^t and for each correlation. The benefits obtained from more transient 
simulation runs are, in no particular order: 


• More confidence that die parameter space has been sampled completely 

• Smaller confidence intervals for the MDNBR statistical parameters 

• The resulting MDNBR distribution has the greater appearance of ‘normality’ 

Here a detailed description of the procedure is given. A detailed sample calculation 
is provided in the ^jpendices: 


• A number, typically 2000, random values with specified statistical properties are 
generated for the five parameters that will be modeled in a Monte Carlo fashion.^ 

• The transient is run for five seconds for each transient^ The MDNBR is 
recorded for each simulation run. 


• After all simulations have been run, the sample mean MDNBR and standard 
deviation are computed. 

These values are computed using standard statistical methods: 




Equation 22 
1 


MDNBR 


{N-l) 


'^MDNBRj -Nfi, 
, 1=1 


2 

■MDNBR 




Where: 

MMDNBR is the sample mean MDNBR, 

& MDNBR is the sample standard deviation of MDNBR, and 
N is the number of samples 


• Using the chi-square distribution, compute the 95% upper confidence limit on tiie 
sample standard deviation. 


ii For tiiis application, random sam p ling of the parameter distributions is employed. More sophisticated 
sampling strategies such as stratified sampling or a Latin Hypercube Sampling (or modified version 
thereof) could be employed in the future as a way to possible reduce the number of samples required. 

“ Ejqierience has shown that, for the transients in this analysis, the MDNBR always occurs at 
approximately 2.5-3.0 seconds, so 5 seconds was deemed sufficient to ensure that the MDNBR was 
obsCTved. 
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These values are also computed using standard statistical methods: 


Eqaation 23 


^MDNBR ~ ^MDNBR ~ 


Where: 


^iiDNBR the estimated population standard deviation** of MDNBR, 
X 2 is the Chi-squared statistical parameter. 


The Chi-squared parameter is a number that is dependent upon the confidence level 
desired for the number of samples taken. 


Equation 24 


;rHc)=' 


1 




2/1 n 


Where: 

c is the desired confidence level 
r is the standard Gamma function 

These values can be obtained from pre-computed matiiematica] tables or 
programmed inverse functions. For the analysis in this thesis, the later route was 


taken.' 


• Using the 95% upper confidence limit standard deviation, compute the 95% lower 
confideace limit mean MDNBR. That is, tiie value that is below tiie actual 
MDNBR mean with 95% probability. 

This is computed using the Student t distribution as follows: 


" ]n diis context, the estimated population standard deviation represents &e standard deviation tiiat the core 
would actually Mve, to a specified degree of confidence, in the presence of the uncertain parameters that 
we have assumed. 

"" Because of the character of the Chi-squared flmction, for analysis witii sample sizes of greater than 
1000, tills step b actually skipped. Microsoft Excel wo^book fimctions were used to obtain values for the 
Chi-squared parameter. For sample sizes above 1000, a floating point exception b returned, resulting in an 
error. As no tabulated values for tiie Chi-squared function were found with very large sample sizes, it was 
assumed therefore tiiat at large values of n, that the sample standard deviation b equal to the population 
standard deviation. 
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Equation 25 


MmmR ~ Mmdnbr 


^^MDNBR 

4n 


Where: 

Mmdnbr is estimated population mean MDNBR, 
r is the Student t parameter, 

^MDNBR is the estimated population standard deviation of MDNBR 


The Student t parameter is computed in a way analogous to the Chi-squared 
parameter. 

• Now adjust the 95% confidence mean MDNBR downward by 1.645 standard 
deviations (the 95% uppa: confidence standard deviation) to find the 95/95 
confidence limits on MDNBR. 

Equation 26 

M95f95-MDNBR ~ MmDNBR ' ~1.645(<Tji^;^®jj) 

Because of the behavior of the Chi-squared and Student t distributions, the 
methodology will result in a more precise calculation of MDNBR as the number of 
random samples is increased. Unfortunately, the precision of the estimate of MDNBR 
only improves in a way proportional to the square root of the number of samples taken.*® 
The question that was to be answered early in the development of this methodology is: 
how many samples should be taken before the benefits of additional samples is 
outweighed by the computational difficulty. 

Figure 31 is given to convey a more quantitative feel for the nature of the 
aforementioned trade-off. The upper plot shows a normalized histogram*® with a series 
of curves superimposed. Each curve represents a normal distribution with the 95 percent 
lower confidence limit mean MDNBR with the 95 percent upper confidence standard 
deviation. As is expected, for an increased number of samples, the curve becomes more 

“ Therefore, to double the precision, four times as many samples must be taken. 

The vertical bars are scaled such Aaf the cumulative area of all bars is equal to one. 
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‘pointed’ to reflect the improved confidence in the computed mean and variance. The 
lower curve shows the corresponding 95/95 confidence mean MDNBR. As this lower 
curve levels off, no additional benefit is accrued by performing additional random 
samples. As can be seen, performing more than about 2000 sample runs has very little 
additional benefit. 


CLOFA- EPRI MDNBR Distributions 



MDNBR 


CLOFA ■ 95\85 MDNBR - EPRI 



F^re 31: Resnhs for large number of Monte Carlo samples for CLOFA using the EPRI 

correlation 
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MCUP Results 


The following graphical results are given for the transient analysis using the MCUP. 
The graphical results are given in the form of a normalized histogram displaying the 
distribution of the sample data.”* Superimposed over the histogram is a cyan line 
showing the normal distribution with a mean value equal to the 95% lower confidence 
mean and 95% upper confidence standard deviation. A vertical magenta line is provided 
to highlight the position of the lower 5* percentile that represents the MDNBR limit for 
the specified correlation and transient. 

LR/SS 


Utss -W3L MDNBR OtUbullofit 
96«6 ConM«ne* MDNBR- 2jOT1 



Figure 32:17x17 W-3L LR/SS MCUP Results. 


The ‘sample data’ is the collection of MDNBR results for the series of random inputs provided to 
VIPRE. 
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F^re 33; 17x17 EPRILR/SS MCUP Results. 



F^re 34:17x17 Bowring LR/SS MCXJP Results. 
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F^re 37:17x17 PLOFA 4 of 8 RCPs EPRI Results. 


PLOFA4 ore Bowrlng MDNBR DMrIbieion 



Figure 38; 17x17 PLOFA 4 of 8 RCPs Bowring Results. 




Probability Dansity Probability Density 


PLOFA4 era • B«W-2 MDNBR Distribution 
96IB6 ConndMicoMDNBR- 2.766 



MDNBR 

Figure 39:17x17 PLOFA 4 of 8 RCPs B&W-2 Results. 


CtOFA-Bewrlng MDNBR Distributions 
9606 Confldmc* MDNBR- 1204 



MDNBR 


Figure 40:17x17 CLOFA Bowriug Results. 
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Figure 41:17x17 CLOFA EPRI Results. 
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Chapters Conclusions 


4.1. Thermal Hydraulic Analysis Results 

The analysis presented in this chapter yields two results: The first pertains to the T/H 
acceptability of the HUS Open core. The second result is a comparison of the uncertainty 
analysis procedures utilized. 

For die reference 1000 MWth IRIS Open core, a numerical summary of die transient 
T/H results is provided in the following tables. 
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Method 

Correlation 

MDNBR 

Limit 

Computed 

MDNBR 

Percent 

Above 

MDNBR 

Limit 

STOP 

EPRI 

1.3 

1.20 

-7.692% 

ITDP 

EPRI 

1.382 

1.296 

-6.223% 

MCUP 

EPRI 

1.3 

1.2360 

-4.923% 

STDP 

Bowring 

1.3 

1.157 

-11.000% 

ITDP 

Bowling 

1.404 

1.276 

-9.117% 

MCUP 

Bowring 

1.3 

1.199 

-7.769% 

MC/Nonn* 

Bowring 

1.3 

1.202 

-7.538% 

STDP 



■SBBI 

-9.000% 

ITDP 

K&m 

■nsH 


44.735% 

STDP 

B&W-2 



-73.030% 

ITDP 

B&W-2 

WBSM 


2.140% 

STDP 

MacBedi 

1.3 

3.868 

197.538% 

ITDP 

MacBeth 

1.382 

4.308 

211.722% 

STOP 

AECL-UO 

1.3 

1.468 

12.923% 

ITDP 

AECL-UO 

1.355 

1.828 

34.908% 


Table 15: C3X)FA Uncertainty Analysb Summary. 


* MC/Norm refers to the use of MCUP with uncertain parameters being described by normal distributions 
wifli the same mean and variance as the same parameters described by a rectangular distributioa 
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Method 

Correlation 

MDNBR 

Limit 

Computed 

MDNBR 

Percent 

Above 

MDNBR 

Limit 

STOP 

EPRI 

1.3 

1.333 

2.538% 

ITDP 

EPRI 

1.382 

1.459 

5.572% 

MCUP 

EPRI 

1.3 

1.385 

6.538% 

MC/Norm** 

EPRI 

1.3 

1.388 

6.769% 

STOP 

Bowring 

1.3 

1.360 

4.615% 

ITDP 

Bowring 

1.404 

1.515 

7.906% 

MCUP 

Bowring 

1.3 

1.431 

10.077% 

STOP 

W-3L 

1.3 

2.021 

55.462% 

UDP 

W-3L 

1.377 

2.238 

62.527% 

MCUP 

W-3L 

1.3 

2.125 

63.462% 

STDP 

B&W-2 

1.32 

2.350 

78.030% 

ITDP 

B&W-2 

1.495 

3.055 

104.348% 

MCUP 

B&W-2 

1.32 

2.755 

108.712% 

STDP 

MacBeth 

■QQiiiim 

MSSS^M 

226.385% 

ITDP 

MacBeth 



243.922% 

STDP 

AECL-UO 

1.3 

1.817 

39.769% 

ITDP 

AECL-UO 

1.355 

1.848 

36.384% 


Table 16: PLOFA Uncertainty Analysis Summary. 


** MC/Norm refers to the use of MCUP with uncertain parameters being described by normal distributions 
with the same mean and variance as the same parameters described by a rectangular distribution. 
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Method 

Correlation 

MDNBR 

Limit 

Computed 

MDNBR 

Percent 

Above 

MDNBR 

Limit 

STDP 

EPRI 

1.3 

1.363 

4.846% 

ITDP 

EPRI 

1.382 

1.495 

8.177% 

MCUP 

EPRI 

1.3 

1.419 

9.154% 

STDP 

Bowring 

1.3 

1.417 

9.000% 

ITDP 

Bowring 

1.404 

1.578 

12.393% 

MCUP 

Bowring 

1.3 

1.487 

14.385% 

STDP 

W-3L 

1.3 

1.961 

50.846% 

ITDP 

W-3L 

1.377 

2.180 

58.315% 

MCUP 

W-3L 

1.3 

2.071 

59.308% 

STDP 

B&W-2 

1.32 

2.249 

70.379% 

ITDP 

B&W-2 

1.495 

2.974 

98.930% 

MCUP 

B&W-2 

1.32 

2.659 

101.439% 

STDP 

MacBeth 

1.3 

4.069 

213.000% 

ITDP 

MacBeth 

1.382 

4.588 

231.983% 

STDP 

AECL-UO 

1.3 

1.711 

31.615% 

ITDP 

AECL-UO 

1.355 

1.763 

30.111% 


Table 17: LR/SS Uncertainty Analysis Summary. 


Because of restrictions on the use of proprietary data, this analysis has not 
incorporated all of the features that will be included in tiie final IRIS T/H design analysis. 
The following is a list of factors that would influence the results, but are not used: 

• Only non-proprietary CHF correlations have been used. None of the correlations 
used in this a^ysis take into account all of die design features of the fuel 
assemblies that will be used in die core. In general, this is expected to impart a 
negative bias on die analysis.® The significant effort expended by fuel vendors to 
improve the thermal performance of their fuel has not been captured. This is 
likely to have the largest impact on the final T/H results. In any case, a proven 
correlation will be critical in the final T/H analysis required to obtain regulatory 
approval of the core design. 

• Only non-proprietary coefficients for various heat-transfer and pressure-drop 
correlations have been used. In general, this is assumed to have a negative bias 
on the analysis. 

• For every analysis conducted in diis study, the fuel was assumed to have a cosine¬ 
shaped power profile. The shape was not changed during any transient. In 


* By ‘negative bias’ it is therefore implied that die results presented here are less fevorable dian diose diat 
would be expected in die analysis conducted by die foel manufacturers. 
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general, this would impart a positive bias on the analysis. The real power projQles 
used by fuel vendors in licensing-level calculations are proprietary. 

• Not all plant uncertainties were considered in this analysis. In particular, no 
accommodation has explicitly been made for core anomalies or transitional core 
conditions. No consideration has been given for degradation of fuel thermal 
performance over the life of the core. Tlie analysis required to accurately predict 
the proper influence of these uncertainties on core T/H behavior is beyond the 
scope of this study. These assumptions would positively bias the analysis. 

• The true statistical imcertainly associated with plant parameters tiiat were 
considered in the analysis: pressure, core inlet temperature, mass flux, linear 
power and were not accurately described. Rather they were assumed to be a 
value rq)resentative of historical designs. This could provide either a positive or 
negative bias to the analysis. 

• Finally, the analysis conducted is based on design and simulations that are 
perpetually in a state of refinement. This could provide either a positive or 
negative bias to the analysis. 

Subject to the above qualifications, this analysis has shown that tiie IRIS core, as 
designed, provides satisfactory T/H margin to accommodate the LR/SS and PLOFA 
transients. Referring to the results presented in Table 15 for the W-3L correlation, 
without the consideration of uncertainty, the IRIS core can also safely cool the core in 
the event of a CLOFA. Complete acceptability of the IRIS core is not demonstrated 
for the CLOFA under conditions of design uncertainty. 

4.2. Comparison of Hot Channel Analysis 
Methodology 

It should be clear that the STDP provides the most conservative result. Within the 
assumptions of the T/H analysis, the plant conditions can never be worse than those used 
for the STDP transient analysis. Therefore, if the plant p«forms satisfactorily under 
those circumstances, the plant must be satisfactory for all conditions expected during 
steady state operations, condition I and condition n transients. It can be seen fi-om the 
results presented in Table 15 - Table 17 that this is the case. 

The ITDP eliminates some of tiie unnecessary conservatism in two ways. First, the 
assumption is made tiiat each imcertain parameter may vary independently of the others. 
This puts a mathematical formalism to the notion that there is a lower jMrobability 
associated with the condition of all uncertain parameters simultaneously achieving their 
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most adverse value. Secondly, rather than aiming for die sort of ‘absolute’ conservatism 
provided by the STDP, a lower mark is placed at ‘acceptable’ conservatism defined by 
the 95% probability with 95% confidence criteria. 

One weakness of the ITDP, as already discussed, is the reliance on a single set of 
values that describes the sensitivity of MDNBR to perturbations in the uncertain 
parameters. It has been shown that these sensitivity parameters are not, in fact constant. 
Therefore tiie requirement to choose a single set of conservative values for these 
parameters adds undue conservatism to the ITDP. This weakness is a fundamental 
property of the mathematical formulation of tiie ITDP, and cannot be avoided. 

Another weakness of the ITDP, is its inability to utilize all of the information present 
in the associated uncertain parameter probability distributions ratiier than simply the 
distribution mean and variance. Consider the case of an uncertain parameter described by 
a rectangular distribution. This distribution has a mean and variance as computed earlier 
in this chapter. Suppose that some additional information was gained regarding this 
uncertain parameter such that, instead of a rectangular distribution, the parameter should 
instead by described by a normal distribution. Suppose further that this normal 
distribution was determined to have the same mean and variance as the rectangular 
distribution. A graphical representation of this is provided in Figure 42. 


Comparison of Rectangular and Normal Distributions 



F^re 42: Normal and Rectangnlar PDFs with identical mean and variance. 
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What would change in the uncertainty analysis if tiie ITDP were used? The answer 
of course is: nothing! The only information that the ITDP uses regarding the probability 
distribution of tiie random parameter is its mean and variance. In contrast, the MCUP 
would automatically take this difference into account - no mathematical meddling 
required. This change in probability distribution has an impact on the behavior of the 
uncertain parameter. Since the ITDP is designed to be conservative, even if tiie change in 
the slKq)e of the probability distribution were feivorable from a T/H standpoint, there 
would be no mechanism for taking this change into account. 

Is this change in the probability distribution of the inlet temperature favorable from a 
T/H standpoint? In this case, it is clear from the above figure that core inlet temperatures 
near the mean value would be more likely. This is a favorable feature insofar as it is less 
likely that the core inlet temperature would be higher than normal. On the other hand, the 
normal distribution has the feature that there is a small, but finite probability tiiat the inlet 
temperature would be significantly outside of the previously dete rmine d band of ± 4 °F. 
This is probably an unfavorable feature since, due to the increase in correlation sensitivity 
as the system approaches CHF (i.e. the core inlet temperature increases) and reduction in 
sensitivity as the system moves fiirther from CHF, the iustances of increased inlet 
temperature would be more detrimental, from a CHF standpoint, tiian the benefit obtained 
from reduced core inlet temperatures. It is not immediately clear whether these two 
factors would combine to be thermal-hydraulically favorable or unfavorable. It turns out, 
as reported using the MCUP, that the combined effect is slightly favorable. This can be 
seen in Table 15 with the Bowring correlation and in Table 16 with the EPRI correlation. 

The MCUP has been shown to consistently produce more favorable thermal- 
hydraulic results with the same level of confidence as the ITDP. To the extent that the 
assumptions governing the T/H analysis are correct, the MCUP is a more accurate 
method to quantify core uncertainties. 
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Chapters Future Work 


5.1. Objectives 

The objectives of future work stemming from this tiiesis can be grouped into three 
categories; 

• Thermal Hydraulic Analysis 

> Qualification of appropriate DNB correlation 

> Develop a complete set of transient analyses 

> Benchmark MCUP methodology to proprietary uncertainty analysis 
procedures. 

> Guidance for Loss of Flow Accident analysis 

• Script-based Interface Tools 

> Extension of interface to integrate plant simulation tools such as RELAP. 

> Migration of interface platform to use non-proprietary software tools. 

• IRIS Open Economic Analysis® 


• Original work provided in Appendix 9. 
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5.2. Scope 

IRIS Open Thermal Hydraulic Analysis 

Qualification of DNB Correlation 

A fundamental component to the T/H analysis of any core is the CHF correlation. 

The quality of this correlation is the cornerstone to the quality of the entire analysis. 

With this said, the CHF correlations used in this analysis must be improved so as to; 

• Be thoroughly tested for validity over the entire range of operational conditions 
ejipected for IRIS. In particular, the correlation must be applicable for the 
relatively low mass-flux conditions that are prevalent for the IRIS reactor, and 

• Fiilly capture the design characteristics of the selected fuel assemblies. 

This qualification will require both experimental tests for IRIS specific bundle 
geometry and operating conditions, and analyses of test results with appropriate VIPRE 
models to develop an IRIS specific DNB correlation based on other Westinghouse 
Proprietary Correlation. 

Develop Complete Set of Transient Analyses 

The various loss of flow accidents that are analyzed in this thesis do not cover the 
full range of casualties that must be considered for the T/H analysis. The full list 
transient analyses that will be required for IRIS is described in reference [21]. 

Benchmark MCUP to Proprietary Uncertainty Analysis Procedures. 

The MCUP must be fairly compared against proprietary vendor-designed uncertainty 
analysis procedures. The MCUP methodology must be expanded to include all 
parameters that the vendor would include in a full uncertainty analysis, and more precise 
specification must be given to more accurately and consistently describe the statistical 
parameters of the uncertain parameters. Upon completion of tiiis task, an evaluation can 
be made comparing the benefit of using MCUP in relation to the additional 
computational burden required in doing so. 
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Guidance for Loss of Flow Accident Analysis 

For a typical core design parametric analysis, or core design in which the main 
objective is not related to thermal hydraulics, it would be useful to have some guidance as 
to how adequate T/H margin for a LOFA could be reasonably verified without actually 
conducting the transient analysis. Given the effort that is required to produce accurate 
analysis results for even a single core design point, such guidance could result in a 
signficiant reduction in computational requirements and ultimately save considerable 
time when performing early feasibility studies for a given core design or engaging in 
broad parametric analysis for a reactor type. 

It is suggested that, to accoimt for the T/H degradation that occurs in a LOFA, a 
steady state analysis could be performed with the nominal coolant flow rate reduced by 
some percentage, whilst maintaining all other design parameters at their nominal best- 
guess values. A study should be conducted to determine how large this pre-determined 
reduction in core flow should be. 

Script Interface Tools 

Extension of Interface To RELAP 

Currently the Matlab-VIPRE interface is deficient in that there is no direct way to 
incorporate the simulation results of a code such as RELAP to allow for a more seamless 
transient T/H analysis. A partial implementation of this is provided in Appendix 8. It is 
recommended that this implementation be completed. 

Migration of Script Interface Tools 

Probably the biggest disadvantage of the current script interface is that it is 
implemented using Matlab and, for the Matlab-VIPRE Interface, Microsoft Excel. 

Though Matlab is a powerful, flexible and user-fiiendly programming environment, the 
effective sharing and collaboration with other potential users and developers of the 
software presented in this thesis may be hindered by the ejpense, albeit nominal of 
acquiring Matlab. Presently, free software tools are available, largely useable with the 
Linux operating system that could supplant proprietary components in every way. 
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The migration of the script interface software to the Linux (or other POSIX- 
compliant operating system) would also open the door towards implementing these tools 
on a parallel distributed platform. As is described in Appendix 2, die sorts of analyses for 
which the Matlab-VIPRE Interface is most suited can also usually take great advantage of 
the capabilities of a Beowulf Cluster such as that vshich is presently available in the 
Nuclear Engineering Department at MIT. Methodologies such as the MUCP that are at, 
or beyond, the hinges of practical design feasibility could be made much more practical 
in this way. 


IRIS Open Economic Analysis 

A fuel cycle cost analysis has been performed for the IRIS Open core in order to 
examine the effect of various fuel management strategies on overall fuel cycle costs. 
Some costs that are not strictly fuel cycle related, namely the cost of replacement 
electricity during refueling and non-planned forced shutdown as well as O&M costs 
related to the refueling are also included as refinements of the basic model. 

It is recommended that tiiis analysis be refined to more accurately reflect the O&M 
costs, for >^ch only a rough, ordra: of magnitude approximation was possible. 
Additionally it is recommended that the Monte Carlo methodology employed to examine 
the composite effect of uncert^ties be refined to more accurately model the uncertainty 
of all parameters considered by employing more closely tailored probability distributions 
and distribution parameters. 
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Chapter? Appendices 








Appendix 1 Integral Reactor Database 

The following is a listing of Integral Reactor Projects. 

Recent and Ongoing Projects 


The following data has been collected from open literature. Blank entries indicate that the data was unavailable or not found. 


Design 

(Associated 

References) 

Power 

(MWfh) 

Primary 

Pressure 

(MPa) 

Primary 

Temp 

(in/out) - “C 

Secondary 

Pressure 

(MPa) 

Integral Configuration 

SGs 

RCPs 

Pressurizer 

IRIS [12] 

1000 

15.5 

292/328 

7 

8 helical coil 
OTSG 

8 - above 

SGs 

Upper Head 

ISIS [28] 

650 

14 

271/310 

4.6 

helical coil 
OTSG 

2- above SG 

External to 
RPV 

SMART [29] 

330 

15 

270/310 

3 

12 helical 
coil OTSG 

4 - mounted 
onRPVHead 

Upper Head 

CAREM-25 [1] 

~75 

(25MWe) 




12 OTSG 


Upper Head 

MRX [30] 

100 

12 

283/298 

4 

Inconel 800 
OTSG 

External to 
core 

Upper Head 
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SIR [31] 

1000 

15.5 

295/318 

5.5 

12 Straight 
tubeOTSG 

Aroimd upper 
circumference 
of vessel. 

Upper Head 

ATEC-200* 

[321,(33] 

700 

15.7 

?/343 

4.4 

Titanium 

OTSG 

Natural 

Circulation 

Upper Head 

-Loaded 

with 

Nitrogen (?) 

AST-500 [32],[34] 

500 

1.96 

134/208 

1.2 


Natural 

Circulation 

Steam/gas 

integral 

VPBER-600 [32] 

1800 

15.7 

?/325 

6.4 




Floating NPP [35] 

2x42 

1 _ 

15.7 

265/310 

3.5 




NHR-5'’ [36]-[38] 

5 

1.5 

146/186 

1.7 


Natural 

Circulation 



Old Projects 


Design 

(Associated 

References) 

Power 

(MWth) 

Primary 

Pressure 

(MPa) 

Primary 
Temp 
(in/out) - *C 

Secondary 

Pressure 

(MPa) 

Integral Configuration 




SGs 

RCPs 

Pressurizer 


* In reference [32], the authors note that the ATEC-200: "...was developed based on design and construction experience obtained with the pilot power units AST- 
500, and the proven design solutions and established technologies of nuclear-powered icebreakers, whos operating performances have been confirmed by about 
40 years of successful operations in Arctic seas.” This is a standardized series of designs: ATEC-80,-150,-200. 

** A larger 200 MWth plant is to be (or has been) built based on the positive experiences and lessons learned from this project. Though some of the operational 
characteristics of this plant are obviously fundamentally different fiom the IRIS, the concept of an integral SG was successfully employed. 
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Otto Hahn 
[39].[40] 

38 

912 psi (fix) 


523 psi 

Helical tube 
OTSG 

Mounted 

External 

Upper Head 

NCS-80 [411,[42] 








CNSG [431-[451 

38 

918 psia 

523/? (F) 

440 psia 

12 straight- 
tube OTSG 

Mounted on 
RPV head 


UNIMOD [46] 

80 

2000-2500 

psia 


640 psia 

6 U-shaped 
tube OTSG 

Mounted 
Astride of 
RPV 


U1U/U2U [46] 

16.5/51.6 

MWe 

1050 psia 

515/545 (F) 

415 psia 

3 OTSG 

Mounted 
Astride of 
RPV 

Integral 

Vulcain [43] 
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Appendix 2 Matlab-VIPRE Interface 

In this section, the code developed for the Matlab-VIPRE Interface is presented and 
explained to a greater depth. The appendix is broken down to describe the major 
features. 

Utility Functions 

The Matlab-VIPRE Interface as described in Chapter 2, requires extensive 
communication between Microsoft Excel, the running scripts within the Matlab 
Workspace context, the file system for input and output files, and the operating system to 
initiate a particular VIPRE execution. 

These functions are short, but represent critical links between the rather routine and 
tedious functions required for input data extraction, input file generation and overall 
execution coordination. 

Communication Between Matlab and Excel 

An absolutely essential ingredient to tiie Matlab-VIPRE Interface is the 
communication pathway between Matlab and Excel. This communication is done 
through ActiveX objects. ActiveX is the Microsoft implementation of the COM protocol 
for inter-process communication. Excel is run as an ActiveX Server, Matlab is the 
ActiveX Client Communication is achieved through function calls fi'om the client to the 
server. 

The first function presented is: get_spreadsheetm. This function takes as an 
argument a fully qualified path name to an existing Microsoft Excel workbook. The 
function returns two objects: first, a handle to the Excel application ActiveX Object,* the 
second is a handle to the qiecific workbook identified by the input argument 

%get_spreacisheet .m 

%function fexcei_actx_obj,spread^sbeet] = get__spreadsheet{file_name) takes as arguements 
%a string literal that is the file-name of the desired spreadsheet. The return values 


* This is just an interface to flie Microsoft Excel application. All inter-process communication functionality 
ultimately is derived fiom this object. 
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%ar6 active-y objects: a spreadsheet that must ultimately be closed via a call to: 

% invoke(spread_sheetr»Close*). The excel_actx_obj must be deleted via a call to: 

% delete (eycel_actx__obj); 

%an e:^cel.Application that must be deleted with a call such as: 

%delete rexcel_actx_obj) 

function [excel_actx_obj,spread^sheet] * get_spreadsheet(file_name) 
excel_actx_obj « actxserver(* Excel.Application *); 

xl_wb - get(excel_actx_obj,’Workbooks*);%creates a handle to the application objects 
workbooks 

spread_sheet * invoke(xl_wb,’Open*,file_name); 


The q)read_sheet object returned from the get_spreadsheet frmction does not directly 
provide access to data within any individual worksheett To do so, one must obtain a 
handle to a particular worksheet object The frmction get_worksheet.m is provided for 
this purpose. 

This frmction accepts as arguments the handle to the Excel workbook in which the 
worksheet resides, as well as a character string that identifies the name of the worksheet 
The frmction returns a handle to the specific worksheet within the workbook. 

%get_worksheet.m 

%takes as arguements the handle to a workbook and a string giving the name of the desired 
worksheet 

%returns a handle to the named worksheet, 

function input_sheet - get_worksheet(workbook,sheet_name) 

input_sheet • get (workbook, * Sheets’,sheet_na 2 ae); %get the input sheet 

The actual data from a particular worksheet may now be accessed through the handle 
to die worksheet object To do so, requires a frmction call dirough this object Wrapper 
frmctions were written to make diis task more intuitive and less error-prone. Two 
versions are used in the input-data extraction scripts they are: get_cell_value.m and 
get_sheet_row_coLm. 

The frmction get_cell_value.m accepts as arguments the handle to die specific 
worksheet that data is beii^ accessed from, and a character string representing die 
specific worksheet cell that is desired.® The return value is the numerical contents of the 
cell^. 

’’ For clarity: A ‘workbook’ is a generic name for a saved Microsoft Excel file. A ‘^readsheet’ is a 
particular ^crosoft Excel spreadsheet. A spreadsheet is composed ofone or more woricsheets. Ihe input 
data is stored on a particular worksheet. 

‘e.g. ‘Al’or'Br. 

* That is - the formulae upon which the displayed numerical cell value is based are not returned. For 
example, if cell B2 is ‘progranuned’ within the ^readsheet to be equal to the sum of ceUs A1 and A2, and 
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%g6t_cell_value.m 

function value = get_cell__value(ws_handle,cell_str) 

range = get(ws_handle,* Range */cell_str,cell_str); 
form = get(range,* Formula'); 
if isempty(form) 

value = ’empty*; %default 

else 

value = get(range,’Value*); 

end 


The function get_sheet_row_col.ni works in a similar fashion, but accepts as 
arguments, a handle to the desired worksheet, and two integers representing the specific 
row and column for which the value is desired. This variant was chosen to allow loop 
indexing within the function call.® The code is as follows: 


%get_sheet_row__col, m 

function val = get_sheet_row_col (ws_handle, row,column) 

cell = get(ws_handle,’Cells *,row,column); 
form = get (cell, * Formula*); 
if iseirpty(form) 
val » * empty *; 

else 

val = get(cell,'Value*); 

end 


Initiation of VIPRE execution 

When the input file has been generated and all is ready for the commencement of a 
VIPRE run, there must be some way in which Matlab can cause VIPRE to begin r unning . 
This sort of functionality is normally made through function calls through the operating 


tile resulting sum is 2, tiien 2 is returned, not the eiqiression A1+A2. If the cell is completely empty, a 
character string ‘empty’ is returned. Normally, when the input extraction scripts are written, it is not 
expected tiiat any of the cells would be empty. The VIPRE input manual allows for de&ult values however 
and the input-generation must account for the &ct that some cells may be onpty, and deal with that 
situation ^propriately, either 1^ inserting tiie de&ult value into the input file, or leaving a blank space 
delimited by a comma. The ‘empty’ return value is provided so that the input generation script can 
distinguish between a variable tiiat should actualty have the value ‘O’, and one that was merety not entered, 
and the defeult value should be used instead (clearly, not necessarily 0). 

* I.e. There is no simple way to automatically loop from A1 to A2 or A1 to B1 in a looping type construct 
within the Matlab language. It is desirable in this respect to have integers represent the row and column of 
tile desired data so that one can easily loop of a series of rows or columns for a series of input data values. 
Additionally, it is useful to allow some flexibility regarding the placement of the input data within a 
specific spreadsheet. I^ for example, the input model is changed by un-lumping a collection of charmels - 
more charmel types may be necessary, this could, dqrending on the organization of the spreadsheet used to 
hold tile iiq>ut data, offret the spreadsheet position of many otiier bits of input data. If an integer index 
variable is used - the portion of the input extraction program can be updated much more quickly and easily 
to reflect a change in position of the input data, than one could if one were using the semantics required in 
the get_cell_value.m frmction. 
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system itself. In Matlab Student version 5.3, for which this interface was written, diere is 
no capability of making operating system calls directly.^ Despite this, Matlab is endowed 
with the capability of being extended through C or Fortran functions. These functions are 
ordinary C or Fortran subroutines* with slight formatting modifications to allow for 
passage of input and output variables firom within tire Matlab workspace context to the 
memory grace allotted for the function. These functions are colloquially referred to as 
‘^ex-files” because the C or Fortran compiler used is called through the Matlab function 
mex (\rith appropriate arguments). A more complete description with more general 
examples of this capability is given in reference [47]. The source code is presented here: 

#mclude ’’mexJi” 

#mdude <5tdlib.h> 

#indude <stdio.h> 

void inexFunction(iiit nlhs, nxArray ^plhsQ, 
int nAs, const mxAfray *p^0) 

{ 

printf("\nCallmg Vipre...\n 
systcmCvipre"); 
return; 

} 


^ As in, through a DOS command line or UNK shell command. In the newest student release of Matlab, 
Version 6.5, diis functionality is provided. 

® Thou^ fliese ‘subroutines’ can have nearly aibitraiy complexity and may invoke any number of other 
subroutines or executable programs, so fliere is no implication here that the ‘subroutines’ have to be simple. 
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Input Data Extraction 

The script employed for input data extraction is an exceptionally fragile portion of 
the interface. Every core model created will require a different script to properly extract 
the data. What is uniform from one input-data-extraction script to the next, are the 
variables in which the data is placed, and the manner in which the data are placed there. 
Additionally, each data extraction script used for this research was based on the fact that 
all of the required input data resides in a Microsoft Excel spreadsheet. 

For the research described here, dozens of different input-data-extraction scripts have 
been used. Presented here is an example of these scripts that demonstrates all of the 
required characteristics of friese scripts. Any researcher wishing to make use of the 
Matlab-VIPRE Interface described in this thesis will need to imderstand how this script 
works to the degree that he or she will be able to create a new script of his or her own. 

This particular script is used to extract input data to run a transient simulation iising 
the W-3L correlation. The difference in the input-data-extraction scripts required for 
transients rather than steady state lie in the requirement to extract the large table of core 
boundary condition data. 

Source Code: 

This function requires die following inputs: 

• input_sheet: This is an ActiveX handle to the Excel Spreadsheet that holds all of 
the input data other than the core boundary condition data required for the 
transient. 

• trans input sheet: This is an ActiveX handle to the Excel Spreadsheet that holds 
all of the core boundary condition data required for the transient. 

• var_file_name: This is a character string specifying the required name for *.mat 
file that will hold the input data. 
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The effect of the function is to place a file** within the current working directory that 
contains (in an easily accessible form') all of the input data required to generate a valid 
VIPRE input file. 

%get_excel_input_trans_M_31 .m 

function get_excel_input_trans_w_31 {input^sheet, trans_input_sheet, var_file^nanie) 


viprel,lease * get_cell_value (input_sheet, ’ A32 *) ; 
viprel•irstrt - get_cell_value(input^sheet, *B32 *); 
viprel,irstep «■ get~cell_yalue(input_sheet,’C32’); 
output^que « char(’viprel*); 

vipre2.text * get_ceUpvalue (input_sheet, ’A33 ’); 
output^que « char(output_que,’vipre2’); 

geoml.inflag » ’geoni'; 

geoxftl.nchanl • get_cell_value(input_sheet, *B40’); 
geoml.ncard * get_cell_value(input_sheet,'C40’); 

if geoml.ncard 0 
con^iressed « 1; 

else 

conpressed * 0; 

end 

geoml .ndx * get_ceUpvalue (input_sheet, • D40 *); 
geoml .nazone « get_ceUpvalue (input_sheet, *E40 *); 
if geoml.nazone ** 0 

unifonn_axial_nodes - 1; 

else 

uniform_axial_nodes * 0; 

end 

geoml,nctyp * get_ceUpvalue (input^sheet, * F40'); 
geoml .mbwr * get_cell_value (input_sheet,'G40M ; 
output_que * char(output_que,’geoml’); 

%start geom2 

if geoml.ndx > 0 

%read geom2 starting with cell a42 
geom2.zz « get_cell_value(input_sheet,*A42’); 
geoin2. theta “ get^cell_value (input_sheet, *B42 ’); 
geoitt2.si » get_cell_value(input^sheet,*C42 *); 
output^que • char(output^que/’geom2’); 

end 

if geoml.nazone > 0 
index * 0; 

for i » 1:geoml.nazone 
index - index +1; 

geom3(i).dx * get_sheet_row_col(input_sheet,44,index); 
index * index+1; 

geom3{i).xboun = get_8heet_row_col(input_sheet,44,index); 

end 

output^que * char (output_que, * geoin3 *); 

end 

if coa^ressed “ 1 

^ This file will have the name *.mat, where the * is replaced by the character string represented by die input 
variable var^filejname. (e.g. where var_filejiaine = ‘runl’, the file will be calledrunLmat) 

' From the previous footnote, to place all of the data fiom this file into the Matlab workspace context, 
simply give the command: load nml 
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%compressecl geometry is used 
%first geomS entry is in row 47 
start_index = 47; 
for i = 1:geoml.nctyp 

index = start_index + (i-l)*4; 
geom5 (i) . mchn = get_sheet_row_col {input_sheet, index ,1); 
geomS (i).carea = get_sheet_row_col(input_sheet,index,2); 
geomS (i) -cpw = get_sheet_row_col {input_sheet, index, 3); 
geom5(i).cph * get_sheet_row_col{input_sheet,index,4); 
index = index + 2; 
for j = l:geom5(i).mchn 

geomS{i,j) * get_sheet_row_col(input_sheet,index,j); 

end 


end 

output_que = char {output_que, * geomS ’, ' geom6 *, ’ geom7 *) ; 

%geom7 cell start is A96 

geom7.nk = get_cell_value (input_sheet, *A96*); 
geom7.ngtyp - get_cell_value{input_sheet,*B96’); 
geom7.ngap = get_cell_value(input_sheet,*C96*); 
geom7.nrow = get_cell_value{input_sheet,'D96’); 
geom7.isym - get_ceUpvalue {input_sheet, *E96’); 
geom7.nsrow = get_cell_value (input_sheet, ’F96*); 

if (geom7.nk > 0) & (geom7.ngap == 1) 

%this means that we read geoml1 — geoml1 starts on line ’A99' 
start_index = 99; 
for i = l:geom7.nk 

index = start_index + (i-1); 

geomll(i).k - get_sheet_row_col (input_sheet, index, 1) ; 
geomll (i) .I = get_sheet_row_col (input_sheet, index, 2) ; 
geoml l(i).J = get_sheet_row_col (input_sheet,index, 3) ; 
geomll(i).width = get_sheet_row_col(input_sheet,index,4); 
geomll(i).cent - get_sheet_row_col(input_sheet,index,5); 

end 

output_que = char(output_que,’geomll*) ; 

end 


end 

%starting rov; is:A132 
propl.inflag = ’prop’; 

propl .nprop *= get_cell_value (input_sheet, ’ B132 ’); 
propl.isteam = get_cell_yalue{input_sheet,’C132*); 
propl.nfprop = get_ceUpvalue(input_sheet,’D132’); 
propl.ipvar = get_cell_value(input_sheet,’E132’); 
output_que = char(output_que,’propl’); 

%rods control group — starts at cell A135 
rodsl.inflag = ’rods’; 

rodsl.naxp = get_cell_value{input_sheet,’B135 *); 
rodsl.nrod = get_cell_value{input_sheet,’C135’); 
rodsl.nc = get_cell_value(input_sheet, *D135'); 
rodsl.nfuelt = get_cell_value{input_sheet,’E135’); 
rodsl.nmat = get_cell_value{input_sheet,’F135’); 
rodsl.igpff = get_cell_value(input_sheet,'G135’); 
rodsl.ngpff = get_cell_value{input_sheet,’H135’); 
rodsl.nopt = get_cell_value(input_sheet,’1135*); 
rodsl-ipowv - get_cell_value{input_sheet,’J135’); 
rodsl.icpr = get_cell_value(input_sheet,’K135 *); 
rodsl.irff = get_cell_value(input_sheet,’L135’); 
output_que = char{output_que,'rodsl'); 

%rods2 starts at cell A137 

rods2.zzh * get_cell_value(input_sheet,’A137’); 
rods2.zstrt = get_cell_value(input^sheet,'B137’); 
rods2.nodals = get_cell_value(input_sheet,’C137’); 
rods2 .nodalt = get__cell_value (input_sheet, ’D137 *); 
output_que - char(output_que,’rods2 *); 








%rods3 starts at cell A139 

rods3.naxn « get_cell_value(input_sheet,»A139*); 
output_que * char(output_que,* rods3 *); 

%rods5 starts at cell A141 

rodsS.pstar « get_cell_value(in.put_sheet, *A141*); 
output_que * char(output_que,* rods5*); 

%rods9 starts at cell A143 
if rodsl.nopt 0 

start_index ■ 143; 
for i = Irrodsl.nrod 

index • start_index + (i-l); 

rods9jpre(i).I - get_sheet_row_col(input^sheet,index,1); 
rods9 jpre (i) . idf uel « get_sheet_row_col { input_sheet, index, 2); 
rods9jpre(i) .radial * get_sheet_row_col(input_8heet,index,3); 
rods9_j>re(i).iaxp » get_sheet_row_col{input_sheet,index,4); 

j * l;%loop index 

cont » l;%logical variable for loop 

%fill remainder of values for rods9 — This is more difficult 
%sinc€ I don't assume knowledge of the number of channels facing 
%each rod — so I have to determine this on the fly. 

%that is the purpose of the following logic 
while(cont 1) 

next_val • get_sheet_row_col (input_sheet, index, 4+j) ; 
if {nextjval 'empty') 
cont » 0/ 
rods9(i,j) * 0; 
continue 

else 

rods9(i,j) « next_val; 

end 

j « j+1; 

end 

end 

end 

output_que * char(output_que,'rods9'); 

%must remember to terminate this list with a zero when generating the input file 

%rods.68 input — for no fuel conduction model 

row_index « 169; 

for i * l:rodsl.nfuelt 

rods68(i).1 * get_sheet_row_col(input^sheet,row_index+(i-l),1); 
rods68 (i) .ftype = get_sheet^row_col (input^sheet7row_index+ (i-l) ,2); 
rods68 (i) .drod - get_sheet_row_col (input_sheet, row_index+ (i-l), 3); 
rods68 (i) .dfuel » get_sheet__row_col (input^sheet,row_index+ (i-l), 4); 
rods68 (i) .nfuel * get_sheet_row_col (input^sheet, row_index+ (i-l), 5) ; 
end ^ ^ 

output_que * char{output_que,'rods68'); 

Input section for fuel conduction model=«^======= 

%ADD RODS.62 input here 
%rods62 starts on cell A169 

%rods62.I * get_cell_value(input_sheet,'A169'); 

%rods62.ftype = 'nucl*; 

%rods62.drod = get^cell^value(input_sheet,*cl69'); 

%rods62.dfuel « get_cell_value(input_sheet,*dl69'); 

%rods62.nfuel = get_cell_value(input_sheet,*el69'); 

%rods62.dcore = get_cell_value(input_sheet,*fl69*); 

%rods62.tclad = get_cell_value(input_sheet,*gl69'); 

%output_que ~ char(output_que,'rods62'); 

%ADD RODS.63 input here 
%rods63 starts on cell A171 

%rods63.iradp - g€t_cell__value (input^sheet, *A17l»); 

%rods63. imatf - get_cell_value (input__sheet,'B171») ; 

%rods63.imatc - get_cell_value(input_sheet,'C171*); 








%rods63.igpc ~ get_cell_value (input__sheet^ *D171 M ; 
%rods63,igforc = get_cell_value(input_sheet,*E171*); 
%rods63-hgap = get_cell_value(input_sheet,* F171M; 
%rods63.ftdens = get_cell_value(input_sheet,*G171»); 
% rods 63. f clad get_ce Upvalue (input_sheet, ’ H171'); 

%output_que = char(output_que,* rods63*); 


%ADD RODS.64 input here 

%start_index == 173; % input starts on row 173 
%cont == 1; 

% count = 0; 

% i ~ 0; 


% 

% 

% 

% 

% 

% 

% 

% 

% 

% 

% 

% 


while(cont ~ 1) 

for j = 1:8 %maximum number of entries in a row in the spreadsheet 
count = count 4 1; 
if (count <- 2*rods63.iradp) 

rods64(count) ~ get_sheet_row_col(input_sheet,start__index4i,j); 

else 

cont 0; 

end 

if (cont == 0) 
j = 9; 
break; 

end 


% end 

% i *= i4l; %move to the next row 

% end 

%output_que = char (output__que, * rods64 *); 


%oper.l input 
%starts on row 177 
start_index = 177; 

operl,inflag * get_sheet_row_col Cinput_sheet, start_index, 1) ; 
oper 1, ih = get_sheet_row_col (input_sheet r start_index, 2); 
operl. ig = get_sheet_row_col {input_sheet, start_index, 3); 
operl. isp = get_she€t_row_col (input_sheet, start_index, 4) ; 
operl.npowr = get_sheet_row_col (input_sheet, start_index, 5) ; 
operl .ndnb = get_sheet_row__col (input_sheet, start_index, 6) ; 
operl. iron = g€t_sheet_row_col (input_sheet, start_index, 7) ; 
operl.ifcvr = get_sheet_row_col(input_sheet,start_index,8); 
operl. luf = get_sheet_row_col (input_sheet, start__index, 9) ; 
operl.ihbal = get_sheet_row_col (input_sheet, start_index, 10); 
output_que =? char (output_que, * operl ’); 

%oper.2 input 
%starts on row 179 
start_index = 179; 

oper2.dps = get_sheet_row_col (input_sheet, start_index, 1); 
oper2.dnbrl - get_sheet_row_col(input_sheet,start_index ,2); 
oper2. fcool = get_sheet_row_col {input_sheet, start_index, 3) ; 
oper2,dnbrc = get_sheet_row_col{input_sheet,start_index,4); 
oper2.ihrod « get_sheet_row__col (input_sheet, start_index, 5) ; 
output_que = char(output^que,* oper2 *); 

%cper.5 input 
%starts on rov/ 181 
start_index = 181; 

operS.pref = get_sheet_row_col(input_sheet,start_index, 1); 
operS.hin = get_sheet_row_col (input__sheet, start_index ,2); 
operS.gin = get_sheet_row_col{input_sheet,start_index,3)/ 
OperS.pwrinp = get_sheet_row_col(input_sheet,start^index,4); 
operS.hout = get_sheet_row_col (input_sheet/start_index, 5); 
output_que = char(output_que,*oper5’); 

%op6r.ll input 

if (operl.isp — 1) i (operl.isp -= 2) 
start_index =183; 

%condition for using oper.11 











%starting row is 183 
cont = 1; 
coiint -0; 
i « 0; 

while(cont 1) 

for j “ 1:8 ^maximum number of entries in a row in the spreadsheet 
count * co\int + 1; 
if (count <=* geoml.nchanl) 

©peril.flofrc(count) *= get_sheet_row_col(input_sheet,start_index+i,j); 
else * 

cont • 0; 

end 

if (cont 0) 
j - 9; 
break; 

end 

end 

i « i+1; %move to the next row 

end 

end 

output_que « char (output_que, ’©peril *); 


%oper.l2 input 
%begins on row 18T 
start_index = 187; 

operl2.np *= get_sheet_row_col(input_sheet,start_index,1); 
operl2 .nh * get_sheet_row_col (input_sheet, start_index, 2); 
operl2.ng * get_sheet_row_col(input_sheet,start_index,3); 
operl2 .nq » get_sheet_row_col (input_sheet/ start_index/ 4); 
operl2 .imath - get_sheet_row_col (input_sheet, start_index, 5); 
operl2.nnatg * get_sheet_row_col(input_sheet,start_index,6); 
output_que *= char (output_que, *operl2*); 

%here, the transient forcing functions need to be read off of the trans_input_sheet. 

%operl3 -- will be stored as an array, - System pressure forcing function 
%the first pair of values will be the initial condition 

operl3 » zeros(abs(operl2.np)*2,1); %a vector containing all of the values 
operl4 * operl3; 
operl7 « ©per13; 
oper20 * operl3; 

%operl3(l) is time zero, and need not be modified 
%operl3(2) is the time zero pressure and is given 
operl3(2) * operS.pref? 

power_col_index « 14; 
flow_col_index * 16; 
time_col_index * 12; 
press_col_index * 15; 
temp_col_index - 17; 

%operl4 — temperature forcing function 
operl4(2) « operS.hin; 

%op6rl7 — inlet flow forcing function 
operl7(2) “ operS.gin; 

%oper20 — power forcing function 
oper20(2) « opetS.pwrinp; 

time_index * 2; 

for i » 3:2:(abs(operl2.np*2)) 

operl3 (i) * get_sheet_row_col (trans_input_sheet, time_index, time_col_index) ; 
operl3(i+l) * get_sheet_row_col (trans_input_sheet, time_index,press_col_index) ; 
operl4(i) * opens (i); - ^ - 

operl7(i) * operl3(i); 
oper20(i) - operl3(i); 






operl4 (i+1) * get_she€t_row_col {trans_input_sheet , time_index, temp_col_index); 
operl7 (i+1) = get_she€t_row_col (trans_input_sheet, time_index, f low_col_index); 
oper20 (i+1) « get_sheet_row_col (trans_input_sheet, time_index, power_col_index) ; 
time_index - time_index + 1; 

end 

output_que « char (output_que, *operl3’) ; 
output_que - char (output_que, * operl4 ’) ; 
output_que = char (output_que, * operl? *); 
output_que = char(output_que, *oper20’) ; 

%group corr begins on row 193 
start_index * 193; 
corrl.inflag = ’corr’; 

corrl.ncor = get_sheet_row_col{input_sheet,start_index,2); 
corrl.nhtc = get_sheet_row_col{input_sheet,start_index,3); 
corrl.ixchf = get_sheet_row_col(input_sheet,start_index,4); 
output_que = char (output_que, ’ corrl ’); 

%corr.2 begins on row 195 
start_index * 195; 

corr2.nscvd = get_sheet_row_col(input_sheet,start_index, 1); 
corr2.nblvd - get_sheet_row_col(input^sheetrstart_index,2); 
corr2. nf rml = get_sheet_row_col (input_sheet , start_index, 3) ; 
corr2.nhtwl = get_she€t_row_col (input_sheet,start__index, 4); 
output_que = char (outpnt^que, ’ corr2 ’); 

%corr.6 begins on row 197 
start_index * 197; 

corr6.nfcon = get_sheet_row_col (input_sheet, start^index, 1); 
corr6 -nsubc = get_sheet_row_col (input_sheet;^ start_index, 2); 
corr6.nsatb = get_sheet_row_col (input_sheet, start_index, 3); 
corr6 .nchfc = get_sheet_row_col (input_sheet, start_index, 4) ; 
corr6. ntrnb = get_sheet_row_col (input_sheet, start__index, 5); 
corr6.nflinb = get_sheet_row_col (input_sheet, start_index, 6); 
output_que = char{output_que,’corr6’); 

%corr.7 given on row 199 
if corr6.nfcon == *epri* 
start_index * 199; 

corr? .cdb = get_sheet_row_col (input^sheet, start_index, 1); 
output_que = char (output_que, * corr?’); 

end 

%corr.9 given on row 201 
start_index « 201; 
for i = 1:corrl.ncor 

corr9.nchf (i,:) = get_sheet_row_col (input_sheet, start_index, i); 

end 

output^que = char (output_que, ’ corr9 ’); 

%corr.ll 

start_index = 203; 

corrll.tdcl = get_sheet_row_col(input_sheet, start_index, 1); 
corr11-spk = get_sheet_row_col(input_sheet,start_index,2); 
corrll.flgrd = get_sheet_row_col(input_sheet,start_index,3); 
output_que = char(output_que,’corr11’); 


% corr.11 and corr.17 commented out due to removal of W-3L and 
% Macbeth DNB correlation from the analysis. This input is no 
% longer needed. If I choose to again analyse using these correlations, 
% I will need to re-adjust the input spreadsheet and this file 

% - also to be adjusted is the parsing routine to account for the 

% reduced number of CHF corellations. 
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% 3S=astsa-sK*-~=a£*aE as ==is£»sa=S53s=ataaijssssss =: ss=s= 

%corr.l6 given on row 205 
%start_in<lex = 205; 

%corrl6.kbwr * get_sheet_row_col(input_sheet,start^index,1); 

%corrl6.nuc = get__sheet_row_col (input_sheet, start_index,2) ; 

%corrl6.cgrid « get_shset_row_col(input_sheet,start_index,3); 

%output_que = char(output_que,'corrl6’); 

%corr.l7 given on row 207 
%start_index = 207; 

%corrl7.mac = get_sheet_row_col(input_sheet,start_index,1); 

%output_gue = char(output_que,'corrl7’); 

%mixing group starts on row 209 with mixx.l 
start_index « 209; 
mixxl.nflag - ‘mixx*; 

mixxl.nscbc * get_sheet_row_col(input_sheet,start_index,2); 
mixxl.nbbc = get_sheet_row_col{input^sheet,start_index,3); 
mixxl .mixk = get_sh€et_row_col (input_sheet, start__index, 4) ; 
output_que = char(output_que,'mixxl*); 

%mixx.2 is given on row 211 
start_index « 211; 

2 aixx 2 .ftm « get_sheet_row_col(input_sheet^ start_index,1); 
mixx2.abeta * get_sheet_row_col ( input_sheet,start_index,2); 
mixx2.bbeta - get_sheet_row_col(input_sheet,start_index,3); 
output_que « char(output_que/'mixx2’); 

if mixxl.mixk ** 1 %then read mixx.3 
%mizing parameters given for each gap 
^number of gaps is given by geom7.nk 
start_index * 213; 

%starting row is 213 
cont « 1; 
count * 0; 
i * 0; 

while(cont ** 1) 

for j ** 1:8 %inaximuin number of entries in a row in the spreadsheet 
count “ count + 1; 
if (count <« 2*geom7.nk) 

mixx3(count) » get_sheet_row_col(input_sheet,start_index+i,j); 
else * 

cont * 0; 

end 

if (cont -* 0) 
j - 9; 
break; 

end 

end 

i * i+1; %move to the next row 

end 

output_que « char (output^que,’rriixx3') / 
end "" 

%drag group starts on row 222 
start_index « 222; 
dragl.inflag « 'drag'; 

dragl.nchtp * get_sheet_row_col(input_sheet,start_index,2); 
dragl.ngptp - get^sheet^row^col(input~sheet,start_index,3); 
dragl,kijopt * get_sheet_row_col(input^sheet/start_index,4); 

Output_que « char(output_que,'dragl*);^ 

if dragl.nchtp > 0 

%drag.2 starts on row 224 
start index « 224; 
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cirag2.atf = get_sheet_row_col (input^sheet, start_index, 1); 
drag2. btf = get_sheet_row_col (input_sheet, start_index, 2) ; 
drag2,ctf - get_sheet_row_col (input_sheet, start__index, 3); 
drag2.alf = get_sheet_row__col (input_sheet, start_index ,4); 
drag2.blf =* get_sheet_row_col(input_sheet,start_index,5); 
drag2. clf = get_sheet_row_col (input_sheet, start_index, 6); 
output_que = char(output_que,’drag2 *); 

end 

if dragl.kijopt > 2 

%drag.7 starts on row 226 
start_index “ 226; 

drag7.ddok = get_sheet_row_col(input_sheet,start_index,1); 
drag7 .ppitch = get_sheet_row_col {input_sheet, start_index, 2); 
output_que = char(output_que,’drag7 *); 

end 

if dragl.ngptp > 0 

%drag.8 starts on row 228 
start_index =228; 

drag8. atg = get_sheet_row_col (input_sheet, start_index, 1) ; 
drags,btg = get_sheet_row_col (input_sheet, start_index ,2); 
drags. ctg = get_sheet_row_col (input_sheet , s tart_index, 3); 
drags.alg = get_sheet_row_col{input^sheet,start_index,4); 
drags.big = get__sheet_row_col (input_sheet, start_index, 5); 
drags. clg = get_sheet_row_col {input__sheet, start_index, 6); 
output_que = char(output_que,’dragS *); 

end 

%grids control group starts in row 233 

gridl.inflag = ’grid*; 
start_index = 233; 

gridl. kept = get_sheet_row_col (input_sheet, start_index, 2) ; 
gridl .nkcor = get_sheet_row_col (input_sheet, start_index, 3); 
output_que = char (output_que, * gridl *); 

%grids.2 given in row 237 
start_index = 237; 
if gridl.kopt == 0 

for i = 1:gridl.nkcor 

grid2 (i) = get_sheet_row_col (input_she€t, start_index, i); 
end 

output_que = char (output_que,’grid2 *); 

end 

%grid.4 given in row 239 
start_index = 239; 

grid4.nci = get_sheet_row_col(input_sheet,start_index,1); 
grid4 .nlev = get__sheet_row_col (input_sheet/ start_index, 2); 
output_que = char (output_que, *grid4 *); 

%grid.6 entries start on row 241 
start_index = 241; 
cont =1; 
count = 0; 
i = 0; 

while(cont == 1) 

for j = 1:8 %inaxiinum number of entries in a row in the spreadsheet 
count = count + 1; 
if (count <= (2*grid4.nlev)) 

grids(count) = get_sheet_row_col(input_sheet,start_index+i,j) 

else 

cont = 0; 

end 

if (cont == 0) 
j = 9; 
break; 


end 







i « i+1; %move to the next row 

end 

output^que » char(output^que,’grid6’); 

%inust terminate the output with a blank entry for grid,4 — 0 when generating the input 
file 

%cont group begins on row 249 

contl.inflag « ’cont*; 

output^que « char(output_que ,*contl’); 

%cont.2 begins on row 251 
start_index « 251; 

cont2. ttdum - get_sheet_row_col (input_sheet, start_index, 1) ; 
cont2,ndtdum « get_sheet_row_col(input_sheetrStart_index,2); 
cont2 .ntrydm « get_sheet_row_col (input^sheet, start_index, 3); 
cont2.itry * get_sheet_row__col (input^sheet, start_index, 4); 
cont2. itrym « get_sheet_row_col (input_sheet, start_index, 5) ; 
cont2.idrect = get_sheet_row_col (input^sheet,start_index,6); 
cont2.itstep « get_sheet_row_col(input^sheet,start_index,7); 
cont2. itmod * get_sheet_row_col (input^sheet, start_index, 8); 
output_que * char(output_que ,’cont2*); ^ 

%ccnt.3 begins on row 253 
start_index • 253; 

cont3. werrx * get^sheet_row_col (input_sheet, start_index, 1) ; 
cont3. werry * get_sheet_row_col {input_sheet, start_index, 2); 
cont3.terror « get_sheet_row_col{input_sheetrStart_index,3); 
cont3, terror ■ get_sheet_row_col (input_sheet, start_index, 4); 
cont3.htcerr * get_sheet_row_col (input^sheet, start_index, 5); 
cont3.daitq)ng * get_sheet_row_col (input_sheet,start_index, 6); 
cont3. accely * get_sheet_row^col (input_sheet, start_index, 7); 
contS.accelf • get^sheet^row^col(input^sheet^ start^index,8); 
output_que « char(output_que, ’cont3*); 

%cont.6 begins on row 255 
start_index » 255; 

cont6.nout « get_sheet_row_col (input_sheet, start_index, 1); 
cont6.npchan « get_sheet_row_col (input_sheet, start_index, 2); 
cont6.npgap « get_sheet_row_col(input_sheet,start_indeXr3); 
cont 6. nprod * get_sheet_row_col (input_sheet , start^index, 4); 
cont 6. npchf « get^sheet^row^col < input_sheet, start_index, 5) ; 
cont6.npwl * get_sheet_row_col (input_sheet/ start_index, 6); 
cont6. nskipt « get_sheet_row_col (input_sheet, start_index, 7); 
cont6 .nskipx * get_sheet_row_col (input_sheet, start_index, 8 >; 
conte.lpopt « get_sheet_row_col (input_sheet, start_index, 9); 
conte.icopt » get_sheet_row_col (input_sheet, start^index, 10); 
cont6 .mfopt - get_sheet_row_col (input^sheet/ start^index, 11).; 
cont6. nodunq) ■ get_sheet_row_col {input_sheet, start^index, 12); 

^cont6.idtail » get_sheet_row_col(input_sheet,start^index,13); 
cont6.idtll * get_sheet_row_col(input_sheet, start_index,14); 
output_que « char (output__que, * cont 6 *); 

%cont.7 given on row 257 
start^index * 257; 

cont7.tmax - get_sheet_row_col (input^sheet, start_index, 1); 
cont7.tprint * get_sheet_row_col(input_sheet, start_index,2); 
cont7.duir 5 >t * get_sheet_row_col(input_sheet,start_index,3) ; 
cont7. tlplot * get_sheet_row_col (input_sheet, start_index, 4); 
cont7.tfiche = get_sheet_row_col(input_sheet,start_index,5); 
cont7. tpdun^ * get_sheet_row_col (input_sheet, start_index, 6); 
output_que » char(output_que,*cont?'); ^ 

out__que *= cellstr (output_que); 

%wlll remember in the input-file generation script, that ENDD and 0 must be at the end of 
the 

%input file 

store the input data to disk 
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%checlc to see if the file currently exists — if it does, delete it: 
if exist(street(var_file_name,’.mat*)) == 2 
delete (street (var_file_name, * .mat *)) ; 

end 

%now save all of the appropriate variables 
save (var_file_name, char (out_que (1))); 
for i - 2:length(out_que) 

save (var_f ile^name, char (out_gue (i)), * -append *); 

end 

%save the out_que itself so it can be used for re-saving a modified version of the 
variables later 

save (var_file__name, * out_que *, * -append*); 
save (var_file_name, * rods9_pre *, * -append*); 
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Input File Generation 

A collection of scripts is used to form a valid VIPRE input file. The input arguments 
are: a character string representing the desired name of the generated input file - e.g. 
‘runl and a character string representing the name of the data file holding the input data 
generated during the input data extraction phase of the run. - e.g. ‘runl var’ or 
‘runl_var.mat’^ 

The interface for input file generation is not complete in the sense that only sufficient 
functionality has been implemented as is required for the project at hand. There is more 
that can be e)q)ressed through the input file fiiat has not been encoded here. The vision is 
that those who require this extra functionality, can make the relatively minor additions to 
the interface that would be required. It was not deemed practical or desireable to 
implement every single feature of VIPRE in die script interface. 

The code is presented here: 


%generat€_input_£il€.m 

Ifunction generate_input_file(input_file_name/var_file_naine> takes as arguements two 
strings 

%indicating the desired name of the vipre input-file, and the name of the file containing 
%the input variables (as generated by get_input_test.in — or an eouivalent function that 
%I develop later that does the same thing) *” 


function generate_input_file (input_file^name,var_file_name) 

load(var_file_naine); %get the variables into the space 
%the functions will be called — hopefully in a good order 

fid « fopen(input_file_name, *w*); 

for i * 1:length(out_que) %one cycle will be required for every entry in the output que 
%every entry in the output que corresponds to a single record in the input file 
%separate functions will be developed to output each individual function to append 
%the desired record to the input file. The input file will be created only by the 
%output function for vipre.1 
switch char(out_que(i)) 
case *viprel» 

gen_viprel(fid,viprel); 
case •vipre2' 

gen_vipre2(fid,vipre2); 
case ’geoml’ 

gen_geoml (fid, geoml) ; 
case »geoin2’ 

gen_geom2 (fid, geoin2) ; 
case *geom3* 

gen_geom3(fid,geom3); 
case *geom5* 

%geom5 implies geom6 — due to the nature of this set of entries, 

%I will generate them together 


^ In the case of files, the sufiBx is optional. 
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gen_geom5_6 (fid, geomS, geom6); 
case 'geom? * 

gen_geom7{fid,geom7); 
case *geomll' 

gen_geomll(fid,geomll); 
case ’propl* 

gen_propl(fid,propl); 
case ’rodsl* 

gen_rodsl(fid,rodsl); 
case *rods2' 

gen_rods2(fid,rods2); 
case *rods3* 

gen_rods3(fid,rods3); 
case *rods5* 

gen_rods5(fid,rods5); 
case 'rods9’ 

gen_rods9(fid,rods9,rods9_pre); 
case 'rods62* 

gen_rods 62 (fid, rods 62); 
case 'rods63' 

gen_rods63(fid,rods63); 
case 'rods64* 

gen_rods64(fid,rods64); 
case 'rods68* 

gen_rods68(fid,rods68); 
case 'rods70* 

gen_rods70(fid,rods70); 
case 'rods71’ 

gen_rods71(fid,rods71); 
case 'operl' 

gen__operl (fid, operl); 
case 'oper2' 

gen_oper2(fid,oper2); 
case 'operS' 

gen_oper5(fid,operS) ; 
case 'operll* 

gen_operll(fid,operll); 
case *operl2' 

gen_operl2(fid,operl2); 
case 'operl3' 

gen_operl3(fid,operl3); 

case *operl4* 

gen__operl4 (fid,operl4) ; 
case * operl7' 

gen_operl7(fid,operl?); 
case 'oper20* 

gej^__oper20 (fid,oper20) ; 
case 'corrl' 

gen_corrl(fid,corrl); 
case 'corr2' 

gen_corr2(fid,corr2); 
case 'corr6’ 

gen_corr6(fid,corr6); 
case *corr7' 

gen_corr7(fid,corr7); 
case 'corr9’ 

gen_corr9(fid,corr9); 
case 'corrll* 

gen_corrll(fid,corrll) ; 
case *corrl3* 

gen^corrl3(fid,corrl3); 
case 'corrl4* 

gen_corrl4(fid,corrl4); 
case 'corrl6' 

gen_corrl6(fid,corrl6); 
case *corrl?' 

gen_corrl7(fid,corrl?); 
case 'corrl3a' 

gen_corrl3a(fid,corrl3a); 
case 'mixxl* 
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genjndxxl (fid,inixxl); 
case *mixx2 * 

gen_ittixx2 (fici,inixx2); 
case *mixx3’ 

gen_mixx3(fid/mixx3); 
case *dragl* 

gen_dragl(fid^dragl); 
case *drag2’ 

gen_drag2{fid,drag2); 
case *drag7* 

gen_drag7(fid,drag7); 
case * drags* 

gen_drag8(fid,drags); 
case *gridl' 

gen^gridl(fid,gridl) ; 
case *grid2* 

gen_grid2(fid,grid2); 
case *grid4* 

gen_grid4(fid,grid4); 
case * grids’ 

gen_grid6(fid,gridS); 
case *contl* 

gen^contl(fid,cent1) ; 
case *cont2’ 

gen_cont2(fid,cont2); 
case ‘contS’ 

gen_cont3(fid,cont3); 
case * cents* 

gen^contS(fid,contS); 
case *cont7’ 

gen_cont7(fid,cont7); 


end 


end 

gen_vipre_ending(fid); 

St * fcloseCfid); 

As can be seen, tiie entries of the character array ‘out_que* are traversed from top to 
bottom. The ordering of the entries in ‘out_que’ is what enforces the correct ordering of 
the ‘cards’ of the input deck as tiiey are generated. 

For each entry of ‘out_que’-that represents an input card for the Vff RE input deck, a 
function is called to write that portion of the input deck to the input file. The arguments 
to each function are an integer representing the file descriptor of the input file, and the 
Matlab-style data structure that holds the data relevant to that input deck. The code for 
these functions is presented here. 


function gen_viprel(fid,viprel) 

kase * nu 2 n 2 str (viprel.kase); 

irstrt * num2str(viprel.irstrt); 

irstep “ nuin2str (viprel .irstep); 

entry « streat(kase,', ’,irstrt,*, *,irstep); 

count - fprintf(fid,’%s \n*,entry); 

function gen_vipre2(fid,vipre2) 
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coiant = fprintf (fid,'%s \n* ,vipre2.text) ; 

function gen_geoml(fid,geoml) 

inflag = streat(geoml.inflag,', *); 
nchanl = streat(num2str(geoml.nchanl),*, ') ; 
ncard =* strcat(num2str (geoml.ncard), *, ') ; 

%ncix = strcat(num2str (geoml,ndx), *); 

ndx * sprintf(’%4.Of,*,geoml.ndx); 
nazone = strcat(num2str (geoml.nazone), M; 
nctyp = streat(num2str(geoml.nctyp ), \ ’); 

if geoml .mbwr == * empty* 

Bobwr = *0*; 

else 

mbwr = num2str (geoml.mbwr); 

end 

entry * streat(inflag,nchanl,ncard,ndx,nazone,nctyp,mbwr); 
count = fprintf(fid,*%s \n*,entry); 
function gen_geom2(fid,geom2) 

count * fprintf(fid,*%7.2f, %3.1f,%4.2f \n*,geom2.zz,geom2.theta,geom2.si); 
function gen_geom3{fid, geomS) 
m = length(geom3); 

num_full_records = floor(m/4); %number of records with a full 4 pairs of entries 
size_partial_record = mod(m,4); %riuinber of entries in a partial record (if any) 

for i = l:num_full_r€cords 
start_index = 4*{i~l); 

for j - 1:4 

index = start_index + j; 
dx = sprintf(*%7.3f*,geom3(index).dx); 
xboun = sprintf(* %7.3f *,geom3(index).xboun); 
if j *= 1 

full_entry = streat(dx,*,*,xboun,*,*); 
elseif j — 4 

full_entry = streat(full_entry,dx,*,*,xboun); 

else 

full_entry = streat(full_entry,dx,’,*,xboun,*,*); 

end 

end 

%full_entry is formed in full — send it to the file 
count = fprintf(fid,*%s \n*,full_entry); 

end 


if num__full_records — 0 
start_index * 0; 

else 

start_index = start_index + 4; 

end 

for j = l:sizejpartial_record 
index = start_index + j; 
dx = sprintf(*%7.3f*,geom3(index).dx); 
xboun = sprintf(* %7.3f *,geom3(index).xboun); 
if j 1 

partial_entry = streat(dx,*,*,xboun,’,*); 
elseif j==size_partial_record 

partial_entry = streat(partial_entry,dx,*,*,xboun); 

else 

partial_entry = streat(partial_entry,dx,',',xboun,*,*); 

end 

end 
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coimt » fprintf(fid, *%s \n*,partial_entry); 

function gen_geom5_6(fid,geomS,geom6) 

nuin_channel_types « length (geomS) ; 

[n,m] » site (geom6); 

for i * l:nuin_channel_types 

mchn * ntiin2str (geomS (i) .mchn); 

carea « sprintf(*%7.3f’,geomS(i).carea); 

cpw * sprintf(*%7.3f’,geomS(i).cpw); 

cph ■ sprintf(*%7.3f’,geomS(i).cph); 

entry * strcat(mchn,*,*,carea,*,*,cpw,*,’,cph); 

count * fprintf(fid,’%s \n*,entry); 

entry - * *; 

cont - 1; %logical variable to get geoznS values 

j “ 1; 

while(cont « 1) 

%there is always at least one channel of the given channel type 
entry « strcat (entry, nuin2str(geom6 (i,j))) ; 
if j < m 
j - j+1; 

if geom6(i,j) < 1 %no legal channel number is less than one 
cont * 0; 

else 

entry « strcat(entry,*,*); 

end 

else 

cont « 0; 

end 

end 

count « fprintf(fid,’%s \n’,entry); %make the geom6 part of the entry 

end 

function gen_geom7 (fid, geom7) 

nk * strcat(num2str(geom7.nk),*,*); 
ngtyp * strcat (niam2str (geom7.ngtyp) ,*,*); 
ngap « strcat(num2str(geom7.ngap),% *); 
nrow * strcat(num2str(georn?.nrow),*,*); 

if geom7.isym ** ’empty* 
isym « *,*; 

else 

isym *= streat (num2str(geom7.isym) ,*,*) ; 

end 

if geom7.nsrow 'empty* 
nsrow » * *; 

else 

nsrow « num2str(geom7.nsrow); 

end 

entry ■ strcat (nk,ngtyp, ngap,nrow, isym,nsrow); 

count “ fprintf(fid,*%s \n*,entry); 

function gen_geomll(fid,geomll) 

num_entries « length(geoml1); 

for i « l:num_entries 

k » strcat(num2str(geomll(i).k) ,*,’); 

I « strcat(num2str(geomll(i).I),*,'); 

J * strcat (niam2str (geomll (i) . J), *, '); 
width « sprintf(*%7.4f,*,geomll(i).width); 
cent • sprintf(*%7.4f',geomll(i).cent); 
entry » strcat(k,I,J,width,cent); 
count * fprintf(fid,*%s \n*,entry); 


end 



function genjpropl(fid,propl) 

inflag = strcat(propl.inflag/*/*); 
nprop =* strcat (num2str (propl .nprop) 
isteam = strcat(num2str(propl.isteam), \ 
nfprop = strcat (num2str (propl .nfprop) 
ipvar = nuin2str (propl.ipvar); 

entry = strcat(inflag,nprop,isteam,nfprop,ipvar); 
count - fprintf(fid,*%s \n',entry); 
function gen_rodsl(fid,rodsl) 
inflag « *rods,*; 

naxp = strcat(num2str(rodsl.naxp),’,’); 
nrod = strcat(num2str(rodsl.nrod) 
nc = strcat(num2str(rodsl.nc),',*); 

if rodsl.nfuelt == * empty’ 

nfuelt = *1,'; 

else 

nfuelt = strcat(num2str(rodsl.nfuelt),’,*); 

end 

if rodsl.nmat — ’empty* 
nmat = *0,*; 

else 

nmat = strcat(num2str(rodsl.nmat),*,’); 

end 

if rodsl.igpff == ’eic^ty* 
igpff - *0,•; 

else 

igpff = strcat (nuia2str (rodsl.igpff ),*,') ; 

end 

if rodsl-ngpff — ’empty* 
ngpff = '0,*; 

else 

ngpff = strcat(num2str(rodsl.ngpff),’,'); 

end 

if rodsl.nopt ’empty* 
nopt = * 0,’; 

else 

nopt = strcat(num2str(rodsl.nopt),*,’); 

end 

if rodsl.ipowv =« ’empty’ 
ipowv = *0,*; 

else 

ipowv = strcat(num2str(rodsl.nopt),*,’); 

end 

if rodsl.icpr “ ’empty’ 
icpr = *0, 

else 

icpr = strcat(num2str(rodsl.icpr),’,’); 

end 

if rodsl.irff -= ’empty’ 
irff = *0’; 

else 

irff = num2str(rodsl.irff); 

end 

entry = strcat(inflag,naxp,nrod,nc,nfuelt,nmat,igpff,ngpff, nopt,ipowv,icpr, irff); 
count = fprintf(fid,* %s \n’,entry); 
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function gen_rods2 (fid, rods2) 

Z2h = strcat (nu2n2str (rods2.zzh), *, *) / 
zstrt « strcat(num2str(rods2.zstrt),’,*); 

if rods2.nodals ■«- *einpty* 
nodals ■ *0,*; 

else 

nodals * streat<nuia2str{rods2.nodals) 

end 

if rods2.nodalt «* ’empty* 
nodalt “ * 0’; 

else 

nodalt * num2str(rods2.nodalt); 

end 

entry «= streat (zzh, zstrt,nodals,nodalt); 

count * fprintf{fid,^ %s \n*,entry); 

function gen^rods 3(fid,rods 3) 

naxn * nuici2str (rods3.naxn); 

count * fprintf(fid,*%s \n’,naxn); 

function gen_rods5(fid,rods5) 

pstar ■ nuin2str (rodsS.pstar); 

count * fprintf(fid,*%s \n’,pstar); 

function gen_rods9(fid,rods9,rods9jpre) 

num^rods * length(rods9_pre); 

[n,m] = size(rods9); 

for i * l:nuin_rods 

I * strcat(nuin2str(rods9_pre(i) •!),*,’); 

idfuel * streat(num2str(rods9_pre(i).idfuel),*,*); 

radial = streat (num2str (rods9__pre (i) .radial),’,’); 

iaxp = niain2str (rods9_pre (i) .iaxp); 

pre^entry - streat(I,idfuel,radial,iaxp); 

cont « 1; 
j “ 1; 

posreentry - * *; 
while(cont 1) 

%will execute at least once and always in pairs of two 
post_entry » streat(post^entry,*,num2str(rods9(i,j))) 
j • j+1; 

post_entry * streat (post^entry, ’,' ,nuin2str (rods9 (i, j))) 

if j «=« ffi %the maximum number of columns in rods9 
cont * 0; 
continue 
end 

%now, look ahead 
j * j+1; 

if rods9(i,j) < 1 
cont *0; 

end 

end 

entry * streat{pre_entry,post_entry); 
count ■ fprintf(fid,*%s \n*,entry); 

end 

end^entry num2str(0); 



count - fprintf(fid/’%s \n’/end_entry); 

function gen_rods62(fid,rods62) 

I = strcat(nuin2str (rods62.1),’/’); 
ftype * *nucl/*; 

drod = sprintf(*%7.4f/*/rods62.drod); 
dfuel = sprintf(’%7.4f,*/rods62.dfuel); 
nfuel = sprintf(* %7.0 f,*,rods 62.nfuel); 
dcore = sprintf(’%7.4f/’/rods62.dcore); 
tclad = sprintf{*%7.4f’/rods62.tclad); 

entry - strcat(I,ftype,drod,dfuel/nfuel/dcore,tclad); 
count = fprintf(fid,*%s \n*,entry); 

function gen_rods 63(fid,rods 63) 

iradp = sprintf {’%7.0f/*/3^o<is63.iradp); 
imatf = sprintf (’%7.Of,'/i^ods63.imatf); 
iitiatc = sprintf (*%7.Of, */rods63.imatc); 
igpc * sprintf{*%7.Of,’/rods63-igpc); 
igforc = sprintf(*%7.Of,*/rods63.igfore); 
hgap = sprintf(*%7.4f,’/rods63.hgap); 
ftdens « sprintf(*%7.4f,*,rods63.ftdens); 
fclad = sprintf(* %7,4 f’,rods 63.fclad); 

entry * strcat(iradp,imatf,imatc,igpc,igforc,hgap,ftdens,fclad); 
count - fprintf(fid,’%s Xn’,entry); 

%this function was pirated from the operll generating function — hence the use of the 
variable 

% ’flofrc’ is inexplicable in this context, but works just as well nonetheless 
function gen_rods64(fid,rods64) 


num_conditions = length(rods64); 

full_lines = floor(num_conditions/8); 
partial__entry_length * mod(num_conditions, 8) ; 

for i = l:full_lines 
entry = '*; 
index - 8*(i-l)+l; 
for j = 1:8 


if j < 8 

flofrc = sprintf(*%7.4f,*/rods64(index)); 
entry = strcat(entry,flofrc); 

else 

flofrc = sprintf(’%7.4f*,rods64(index)); 
entry *= strcat (entry, flofrc); 

end 

index * index +1; 

end 

count * fprintf(fid,*%s \n*/entry); 

end 

index = 8*full_lines + 1; 
entry = * S* 

for j = l:partial_entry_length 

if j < partial_entry_length 

flofrc = sprintf{*%7.4f,’/rods64(index)); 
entry = strcat(entry,flofrc); 

else 

flofrc = sprintf (’%7.4f\ rods64 (index)); 
entry = strcat,(entry, flofrc) ; 

end 

index = index + 1; 

end 

count = fprintf(fid,’%s \n’/entry); 
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function gen_rods68(fid,rods68) 
num_rods « length(rods68)? 
for i » l:num_rods 

I “ street(num2str(rods68(i).1); 
ftype * street(num2str(rods68(i).ftype),* 
drod » sprintf(*%7.4f,*,rods68(i).drod); 
dfuel « sprintf(^%7.4f,*,rods68(i).dfuel) 
nfuel « nuin2str {rods68(i) .nfuel); 
entry « street(I,ftype,drod,dfuel,nfuel); 
count ■ fprintf(fid,*%s \nentry); 

end 

function gen_rods70(fid,rods70) 

n * sprintf(*%7.0f,’,rods70.n); 
nntdp * sprintf(*%7.Of,’,rods70.nntdp); 
rcold « sprintf('%7.4f’,rods70.rcold); 

entry - street(n,nntdp,rcold); 
count * fprintf(fid,*%s \n’,entry); 

function gen_rods7l(fid,rods71) 

[n,m] “ size(rods71); 

for i*l:n 

tprop * sprintf(*%7.1f’, rods71(i,1))/ 
cpff * sprintf(*%7.5f’, rods71{i,2)); 
thef « sprintf(*%7.5f», rods71(i,3)); 

if (rem(i,2)“-0) 

entry « street(tprop,,cpff,,thcf) 
fprintf(fid,*%s\n*,entry); 
else 

entry * street(tprop,’,*,cpff,’,’,thcf, 
fprintf(fid,entry); 

end 

end 

function gen_operl(fid,operl) 
infleg * *oper,*; 

ih * street(num2str(operl,ih),',*)/ 
ig » street(num2str(operl,ig),*,*)/ 
isp “ street (nu 2 n 2 str (operl.isp) ; 

npowr * street (nuin2str (operl .npowr) ,*,*); 
ndnb « street (nuin2str (operl .ndnb) ,*,*); 

if operl.irun ** ’empty* 
irun * *1,*; 

else 

irun * street (n\im2Str (operl.irun) ,’,*); 

end 

if operl.ifevr ■« 'empty* 
ifevT « *0,'; 

else 

ifevr * street (niiin2str (operl.ifcvr) ,*,*); 

end 

if operl.luf « ’empty* 
luf * *0,*; 

else 

luf “ street(num2str(operl.luf),*,*); 

end 

if operl.ihbel -■ ’empty* 






ihbal = *0»; 

else 

ihbal = num2str(operl.ihbal); 

end 

entry = strcat (inflag, ih, ig,isp,npowr,ndnb,ir\in, ifcvr,luf, ihbal); 

count fprintf (fid,’%s \n*,entry); 

function gen_oper2{fid,oper2) 

dps “ sprintf (*%7.4f, \oper2.dps); 
dnbrl = sprintf('%7.4f,*,oper2.dnbrl); 
fcool = sprintf('%7.4f,*,oper2.fcool); 
dnbrc = sprintf('%7.4f,’,oper2.dnbrc); 

if oper2.ihrod =- 'empty’ 
ihrod = *0*/ 

else 

ihrod = num2str(oper2.ihrod); 

end 

entry = strcat(dps,dnbrl,fcool,dnbrc,ihrod); 

count = fprintf(fid,*%s \n*,entry); 

function gen_oper5(fid,operS) 

pref = sprintf(’%7.4f,*,oper5.pref); 
hin = sprintf(’%7.4f,*,oper5.hin); 
gin = sprintf(’%7,4f,*,OperS.gin); 
pwrinp - sprintf(’%7.4f,’,OperS.pwrinp); 

if operS.hout =» ’empty’ 
hout = ’O’; 

else 

hout - nu2n2str (operS.hout); 

end 

entry = strcat(pref,hin,gin,pwrinp,hout); 
count = fprintf(fid,’%s \n’,entry); 
function gen_operll(fid,operll) 


num_conditions = length(operll.flofrc); 

full_lines = floor(num_conditions/8); 
partial_entry_length = mod(num_conditions,8); 

for i = l:full_lines 
entry = ” ; 
index = 8*(i“l)+l; 
for j = 1:8 


if j < 8 

flofrc = sprintf(’%7.4f,’,operll.flofrc(index)); 
entry = strcat(entry,flofrc); 

else 

flofrc = sprintf('%7.4f’,operll.flofrc(index)); 
entry * strcat(entry,flofrc); 

end 

index = index +1; 

end 

count * fprintf(fid,’%s \n’,entry); 

end 

index = 8*full_lines + 1; 
entry = ’’; 

for j = l;partial_entry_length 
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if j < partial_entry_length 

flofrc * sprintf(*%7.4f,*,operll.flofrc(index)) 
entry * strcat(entry,flofrc); 

else 

flofrc « sprintf(’%7.4f*,operll.flofrc(index)); 
entry * strcat(entry,flofrc); 

end 

index « index +1; 

end 

coimt “ fprintf (fid, *%s \n*,entry); 

function gen_operl2(fid,operl2) 

if operl2.np ‘empty* 
np - *0,*; 

else 

np » strcat(nuin2Str{oper 12.np),*,*); 

end 

if operl2.nh ‘en^ty* 

nh « *0,*; 

else 

nh - strcat(num2str(operl2.nh),*,*); 

end 

if operl2.ng = ’empty* 
ng - *0, 

else 

ng » strcat (nuin2str(oper 12.ng) ,*,*); 

end 

if operl2.nq ‘en^ty* 

nq * *0, *; 

else 

nq • strcat(nuia2str(operl2.nq) ,*,‘); 

end 

if operl2.nnath ’empty* 

nnath * *0,•; 

else 

nnath * strcat (nuia2str (operl2 .nnath) ,*,*); 

end 

if operl2,nnatg ’enpty* 

nnatg « * 0 *; 

else 

nnatg - nuin2str(operl2.nnatg); 

end 

entry * strcat(np,nh,ng,nq,nnath,nnatg); 

count « fprintf(fid,’%s \n*,entry); 

function gen_operl3(fid,operl3) 

n\jm_conditions • length (oper 13); 

full^lines « floor(num_conditions/8); 
partial_entry_length * mod(nuin_conditions, 8) ; 

for i « l:full_lines 
entry * ”; 
index *= 8*(i-l)+l; 
for j * 1:8 

if j < 8 

flofrc * sprintf(*%7.4f,•,operl3(index)); 
entry - strcat(entry,flofrc); 

else 

flofrc • sprintf(*%7.4f*,operl3(index)); 
entry « strcat(entry,flofrc); 






end 

index = index + 1; 

end 

count = fprintf(fid,’%s \nentry); 

end 

index = 8*full_lines + 1; 
entry = * *; 

for j = l:partial_entry_length 

if j < partial_entry_length 

flofrc * sprintf{*%7.4f,’,operl3(index)); 
entry = strcat(entry,flofrc); 

else 

flofrc = sprintf(’%7.4f*,operl3(index)); 
entry = strcat(entry,flofrc); 

end 

index = index +1; 

end 

if(partial_entry_length >= 1) 

count = fprintf(fid,’%s \n*,entry); 

end 

function gen_operl4(fid,operl4) 

nuin_conditions - length (operl4); 

full_lines = floor(num^conditions/8); 
partial_entry_length = niod(nuin_conditions, 8); 

for i = l:full_lines 
entry * ’’; 
index = 8*(i-l)+l; 
for j = 1:8 

if j < 8 

flofrc = sprintf(»%7,4f,*,operl4(index)); 
entry = strcat(entry,flofrc); 

else 

flofrc - sprintf{*%7.4f’,operl4(index)); 
entry - strcat(entry,flofrc); 

end 

index = index +1; 

end 

count = fprintf (fid, *%s \n\entry); 

end 

index = 8*full_lines +1; 
entry = * *; 

for j - l:partial_entry_length 

if j < partial_entry_length 

flofrc = sprintf(*%7.4f,*,oper14(index)); 
entry = strcat(entry,flofrc); 

else 

flofrc = sprintf(*%7.4f’,operl4(index)); 
entry = strcat(entry,flofrc); 

end 

index = index + 1; 

end 

if(partiai_entry_length >= 1) 

count = fprintf(fid,* %s \n',entry); 

end 

function gen_operl7(fid,operl7) 
num_conditions = length(oper17); 
full_lines = floor(num_conditions/8); 
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partial_entry_length - mod(num_conditions,8); 

for i * l;full_lin€s 
entry * »*7 
index * 
for j « 1:8 

if j < 8 

flofrc = sprintf(»%7.4f,*,operl7(index)) 
entry * strcat(entry,flofrc); 

else 

flofrc • sprintf(*%7.4f^operl7(index)); 
entry « strcat(entry,flofrc); 

end 

index * index + 1; 

end 

count « fprintf(fid,*%s \n*,entry); 

end 

index * 8*full_lines +1; 
entry « •»; 

for j * l:partial_€ntry_length 

if j < partial_entry_length 

flofrc « sprintf(’%7.4f,*,operl7(index)); 
entry « strcat(entry,flofrc); 

else 

flofrc « sprintf(*%7.4f’,operl7(index)); 
entry » strcat(entry,flofrc); 

end 

index * index +1; 

end 

if (partial_€ntry_length >« 1) 

count *» fprintf (fid, *%s \nSentry); 

end 

function gen_oper20(fid,oper20) 

num^conditions * length(oper20); 

full_lines « floor(num_conditions/8); 
partial_entry_length » mod(n\ 2 in_conditions, 8); 

for i « l:full_lines 
entry *= *'; 
index « 8*(i-l)+l; 
for j - 1:8 

if j < 8 

flofrc *= sprintf (’%7.4f, *,oper20(index)) 
entry * strcat(entry,flofrc); 

else 

flofrc “ sprintf{*%7.4f’,oper20(index)); 
entry * strcat(entry,flofrc); 

end 

index » index +1; 

end 

count * fprintf(fid,*%s \n*,entry); 

end 

index « 8*full_lines + 1; 
entry « ’'; 

for j » l;partial_entry_length 

if j < partial_entry_length 

flofrc « sprintf(»%7.4f,',oper20(index)); 
entry « strcat(entry,flofrc); 

else 

flofrc - sprintf(»%7.4f*,oper20(index)); 
entry « strcat(entry,flofrc); * 




end 

index = index + 1; 

end 

if (partial_entry_length >= 1) 

count = fprintf(fidr*%s \nentry); 

end 

function gen_corr1(fid,corr1) 

inflag = *corr,*; 
ncor = strcat(num2str(corrl.ncor) 
nhtc = strcat(num2str(corrl.nhtc)/*,*); 
if corrl.ixchf == * empty* 
ixchf = *0'; 

else 

ixchf = num2str(corrl.ixchf); 

end 


entry = strcat(inflag,ncor,nhtc,ixchf); 

count ~ fprintf(fid,*%s \n*,entry); 

function gen_corr2(fid,corr2) 

nscvd = strcat(corr2.nscvd,*,*); 
nblvd = strcat(corr2.nblvd,*,*); 
nfrml * strcat(corr2.nfrml,*,*); 
nhtwl = strcat(corr2.nhtwl,*,*); 
entry * strcat (nscvd,nblvd, nfnal, nhtwl); 
count = fprintf(fid,*%s \n*,entry); 

function gen_corr6(fid,corr6) 

if strcn^) (corr 6. nf con, * empty*) == 1 
nfcon - * epri,*; 

else 

nfcon = strcat(corr6.nfcon,*,*); 

end 

if strcmp(corr€.nsubc,’empty*) == 1 
nsubc * *thsp,*; 

else 

nsubc = strcat(corr6.nsubc,*,*); 

end 

if strcn^(corr6.nsatb,'empty*) = 1 
nsatb = *thsp,*; 

else 

nsatb = strcat(corr6.nsatb,*,*); 

end 

if strong (corr6.nchfc,’empty') *= 1 
nchfc = * epri,*; 

else 

nchfc = strcat(corr6.nchfc,*,*); 

end 

if strcmp(corr6.ntrnb,’empty*) == 1 
ntrnb = * cond,*; 

else 

ntrnb * strcat(corr6.ntrnb,’,*); 

end 

if strcn^(corr6.nflmb,'empty*) *= 1 
nfImb = 'g5.7,*; 

else 

nflmb = strcat(corr6.nfImb,*,*); 

end 
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entry * street (nfcon, nsubc,nsatb,nchfc,ntrnb,nflinb); 

count = fprintf(fid, •%s \nSentry); 

function gen_corr7(fid,corr7) 

cdb « sprintf(*%7.4f’,corr7.cdb); 

count * fprintf(fid,»%s \n*,cdb); 

function gen_corr7(fid,corr7) 

cdb « sprintf(*%7.4f’,corr7.cdb); 

count » fprintf(fid,’%s \n’,cdb); 

function gen_corr9(fid,corrS) 

(num_corrs,ml « size{corr9.nchf); 

entry ■ * *; 

for i » linm^corrs 

entry * street(entry,corr9.nchf(i,:),*,*); 

end 

count * fprintf(fid,*%s \n*,entry)? 

function gen_corrll(fid,corrll) 

tdcl * sprintf(*%7.4f,*,corrll.tdcl)? 
spk = sprintf (’%7.4f,’,corrll.spIc) ; 
flgrd * sprintf{*%7.4f’,corrll.flgrd); 

entry « street(tdcl,spk,flgrd)? 

count ■ fprintf(fid,*%s \n’,entry); 

function gen_corrl3(fid,corrl3) 

fvane* sprintf(* %7,4f’,corrl3,fvane); 

entry « fvane; 

count * fprintf(fid,*%s \n*,entry); 
function gen_corrl4(fid,corrl4) 

%this is a hack — only works for models where all of the channels are of a given type. 

nchan ■ street(num2str{corrl4.nchan),*,*); 

mtp ■ nuiB2str {corrl4.mtp) ; 

entry « streat(nchan,mtp)? 

count « fprintf(fid,*%s \n*,entry); 

function gen_corrl6{fid,corrl6) 

kbwr « streat (nuin2str(corrl6.kbwr) ; 

nuc « streat (nuin2str(corrl6.nuc) ,*,*); 
egrid « sprintf(’%7,4f*,corr16.egrid); 

entry * streat(kbwr,nuc,egrid); 

count • fprintf(fid,’%s \n’,entry)? 

function gen_corrl7(fid,corrl7) 

mac « nuin2str (corrl7.mac); 

count » fprintf (fid, *%s \n’,raac); 
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For using the KfK correlation, added to VIPRE by Jacopo Saccherri,^^®^ the 
additional card, aititled “corrlSa” is required. According to the input rules for VIPRE 
this card must be placed after the supplementary input cards for the other correlation. For 
this reason, it is not in it’s logical location (e.g. just after the entry for corrlS). 

function gen_corrl3a (fid,corrl3a) 

h= sprintf(*%7.4f,*,corrlSa.h); 
p= sprintf(*%7.4f,’,corrlSa.p); 
d= sprintf ('%7.4f %corrl3a.d); 

entry = strcat(h,p,d); 

count = fprintf{fid,’%s \n*,entry); 

function gen_mixxl(fid,mixxl) 

nflag = ’mixx,*; 

nscbc = strcat (nuin2str (mixxl.nscbc) 
nbbc = strcat(num2Str(mixxl.nbbc); 
mixk = num2str (mixxl.mixk); 
entry = strcat(nflag,nscbc,nbbc, mixk); 
count ~ fprintf(fid,*%s \n*,entry); 

function gen_mixx2{fid,mixx2) 

ftm = sprintf (*%7.4f, *,mixx2.ftm); 
abeta = sprintf(’%7.4f,’,mixx2.abeta); 
bbeta - sprintf('%7.4f',mixx2.bbeta); 
entry = strcat(ftm,abeta,bbeta); 
count = fprintf(fid,’%s \n’,entry); 

function gen_jaixx3 (fid, mixx3) 

num_entries * length(mixx3); 

num_full_entries = floor(num_entries/8); 
si 2 e_partial_entry - mod(num_€ntries,8); 

for i = l:num_full_entries 
entry = * *; 
index = 8*(i-l) + 1; 
for j =1:8 

num = sprintf(’%7.4f,’,mixx3(index)); 
entry = strcat(entry,num); 
index = index +1; 

end 

count = fprintf(fid,’%s \n’,entry); 

end 

index = 8*num_full_entries +1; 
entry = * *; 

for i = l:sizejpartial__entry 

num = sprintf(*%7.4f*,mixx3(index)); 
if i == size_partial_entry 

entry = strcat(entry,num); 

else 

entry = strcat (entry, nxun, ’, *); 

end 

index = index + 1; 

end 

count = fprintf(fid,’%s \n*,entry); 
function gen_dragl(fid,dragl) 
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inflag « ’drag,’; 

nchtp *= strcat(nuin2str(dragl.nchtp), 
ngptp * strcat {nuin2str{dragl.ngptp), ; 

%kijopt = strcat (nuin2str(dragl.kijopt) ,*,») ; 
kijopt • num2str(dragl.kijopt) ; 
entry • strcat(inflag,nchtp,ngptp,kijopt); 
count * fprintf(fid,'%s \n*,entry); 

function gen_drag2(fid,drag2) 

atf * sprintf(’%7.4f,’,drag2.atf); 
btf « 5printf(’%7.4f,’,drag2.btf); 
ctf « sprintf(’%7.4f,’,drag2.ctf)/ 
alf - sprintf(»%7.4f,’,drag2.alf); 
blf * sprintf(•%7.4f,’,drag2.blf); 
clf « sprintf(»%7.4f',drag2.clf); 
entry - strcat(atf,btf,ctf,alf,blf,clf>; 
count « fprintf(fid,*%s \n’,entry); 

function gen_drag7{fid,drag7) 

ddok « sprintf(»17.4f,*,drag7.ddok); 
ppitch * sprintf(’%7.4f’,drag7.ppitch); 
entry » strcat(ddok,ppitch); 
count - fprintf(fid,’%s \n’,entry); 

function gen_drag8(fid,drag8) 

atg - sprintf(’%7.4f,•,drag8.atg); 
btg « sprintf(’%7.4f,’,drag8.btg); 
ctg - sprintf(’%7.4f,drags.ctg); 
alg * sprintf(’%7.4f,drags.alg); 
big - sprintf(’%7.4f,’,drags.big); 
clg « sprintf(’%7.4fdrags.clg); 
entry - strcat(atg,btg,ctg,alg,big,clg); 
count - fprintf(fid,’%s \n’,entry); 

function gen_gridl(fid,gridl) 

inflag « ’grid,*; 

kopt » strcat (nuin2str (gridl. kopt) ,’,’); 
nkcor » num2str(gridl.nkcor); 
entry - strcat(inflag,kopt,nkcor); 
count » fprintf(fid,’%s \n’,entry); 

function gen_grid2(fid,grid2) 

num^coeff « length(grid2); 
full_records » floor(num_coeff/8); 
length_partial_reccrd « mod(nuin_coeff, 8); 

for i - l:full_records 
entry » *'; 
index « 8*(i-l)+l; 
for j « 1:8 

num * sprintf(’%7.4f,»,grid2(index)); 
entry - strcat(entry,num); 
index - index + 1; 
end 

count « fprintf(fid,’%s \n’,entry); 

end 


index « 8*full_records + 1; 
entry * * ’; “* 

for j - l:length_j)artial_record 

num « sprint f(* % 7.4 f»,grid2(index)); 
if j length_jpartial_record 
entry - strcat(entry,num); 

else 

entry « strcat(entry,num,’,’); 





I 


[ 



I 
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end 

index « index +1; 

end 

count = fprintf(fid,*%s \n*,entry); 

function gen_grid4(fid, grid4); 

nci « street (nuin2str (grid4 .nci) 
nlev - nuin2str (grid4.nlev); 
entry = street(nci,nlev); 
count = fprintf(fid,*%s \n*,entry); 

function gen_grid6(fid,grid6) 

num_entries = length(grid6); 

niua_j)eirs ® num_entries/2; 

nuia^records = ceil (nuinjpeirs/8); 

num_full_records = floor (nuin_peirs/8); 
lenjpertiel_record = mod(num_peirs,8); 
if len_j>ertiel_record > 4 
rows_pertiel_record =2; 

else 

rows_pertiel_record =1; 

end 


for i = l:num_full_records 
index = 16*(i-l)+l; 
for rows ~ 1:2 
entry = ’*; 
for j = 1:4 

exj = sprintf( *%7.4f, *,grid6(index)); 

index = index + 1; 

if (j == 4) & (rows == 2) 

kor nuin2str (grid6(index)) ; 

else 

kor = street(num2str(grid6(index)),’,')/ 

end 

entry = street(entry,exj,kor); 
index = index +1; 
end 

if rows == 1 

entry = street(entry,’?*)? 
end 

count = fprintf(fid,*%s \n’,entry); 

end 

end 

index - 16*nuin_full_records + 1; 

%must account for the possibility that a single record will now 
%require more than one row of output, (i.e. need a continuing *?') 

if rows_partial_record “ 1 

num_entries_reinaining = num_entries - (index - 1); 
entry = * *; 

for j = l:2:num_entries_remaining 

exj = sprintf(* %7.4f,',grid6(index)); 
index = index+1; 
if j == nuia_entries_remaining 
kor = nuia2str (grid6 (index)); 

else 

kor « street(num2str(grid6(index)),*,'); 

end 

entry * street(entry,exj,kor); 
index = index+1; 

end 

count = fprintf(fid,’%s \n',entry); 
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elseif rows_partial_record ■« 2 
%dc the first row 
entry *= * *; 
for j *= 1:4 

axj « sprintf(*%7.4f,*,grid6(index)); 
index - index + 1; 

kor * street(num2str(grid6(index)),*/*); 
entry » street(entry,axj,kor); 
index « index + 1; 

end 

entry ■ streat(entry,*?*); 

count * fprintf(fid,*%s \n’,entry); 

%now do the remaining full/partial row 
num_entries_remaining « num_entries - (index - 1); 
entry * * *; 

for j * 1:2:num_entries_reinaining 

axj = sprintf(*%7.4f,*,grid6(index)); 
index * index +1; 
if j «* nuiti_entries_reinaining 
kor « nuin2str(grid6 (index)); 

else 

kor * streat (nuin2str (grid6 (index) ),*,*); 

end 

entry * streat(entry,axj,kor); 
index * index +1; 

end 

coxmt = fprintf (fid, *%s \n*,entry); 


end 

%generate the terminating 0 entry for grid.4 
count « fprintf(fid,*0 \n*); 

funetion gen_contl(fid,contl) 

inflag * nuin2str (contl .inflag) ; 
count = fprintf(fid,*%s \n*,inflag); 

function gen_cont2(fid,cont2) 

if strcinp{cont2.ttduin,’empty’) «= 1 
ttdum “ *0.0,’; 

else 

ttdum - sprintf{’%7.4 f,*,cont2.ttdum); 

end 

if strcnp(cont2.ndtdum,’enpty*) «« 1 
ndtdum » *0,*; 

else 

ndtdum « streat (nuin2str (cont2 .ndtdum) ,*,*); 

end 

if strcii¥>(cent2.ntrydm,'empty*) ** 1 
ntrydm ■ ’20,’; 

else 

ntrydm « streat (nuin2str(cont2.ntrydm) ,*,’) ; 

end 

if stremp(cont2.itry,'empty*) 1 

itry »*50,’; 

else 

itry * strcat(num2str(cont2.itry); 

end 

if stremp(cont2.itrym,'empty’) 1 
itrym = *2,*; 

else 

itrym ■ streat(num2str(cont2.itrym),’,*); 

end 
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if strcitp(cont2.idrect,’empty’) == 1 
idrect = *1,*; 

else 

idrect = street(num2str(cont2.idrect); 

end 

if strcmp(cont2.itstep/’empty*) — 1 
itstep = *0,*; 

else 

itstep = street(num2str(cent2.itstep),’,*); 

end 

if strcn^(cont2.itmod,’err^ty*) == 1 
itmod = *1’; 

else 

itmod = num2str(cont2.itmod); 

end 

entry = street (ttdum,ndtdum,ntrydm, itry, itrym, idrect, itstep, itmod); 
count = fprintf(fid,* %s \n’,entry); 

function gen__cont3 (fid, cont3) 

if strcmp(cont3.werrx,’empty’) — 1 
werrx = * 0.10,*; 

else 

werrx - sprintf(*%7,4f,*,cont3.werrx); 

end 

if strcmp(cont3.werry,’empty*) == 1 
werry - *0.00001,*; 

else 

werry = sprintf(*%7.5f,*,contS.werry); 

end 

if stremp(cont3.ferror,’empty*) == 1 
ferror * *0,001,*; 

else 

ferror = sprintf(’%7.5f,’,cont3.ferror); 

end 

if stremp(cont3.terror,’empty') =- 1 
terror « *0.05,*; 

else 

terror = sprintf(*%7.5f,',cont3.terror); 

end 

if stremp(contS.htcerr,’empty*) == 1 
htcerr = *0.01,’; 

else 

htcerr = sprintf(’%7.5f,*,cont3.htcerr); 

end 

if stremp (cont3. dairying, * empty *) == i 
dan^ng = *0.9,*; 

else 

danpng = sprintf(’%7.5f,*,cont3.dampng); 

end 

if stremp(cont3.accely,'empty*) == 1 
accely * * 1.5,*; 

else 

accely = sprintf('%7.4f,’,cont3.accely); 

end 

if stremp(contS.accelf,’empty’) “ 1 
accelf = *1.0’; 

else 

accelf = sprintf(*%7.4f’,cont3.accelf); 

end 
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entry • street (werrx,werry, terror,terror,htcerr,dait^ng,accely,accelf) ; 
count * fprintf(fid,*%s \n’,entry); 

function gen_cont6(fid,cont6) 

nout * streat(num2str(contS.nout) 
npchan « streat (nuin2str (cont6.npchan) ,*,*); 
npgap » streat (nuin2str (eont6 .npgap) ,*,*); 
nprod » streat(num2str(cont6.nprod),*, »); 
npehf * streat(numSstr(cont6.npchf),*,M; 

if stream(cont6.npwl,’empty’) 1 
npwl * *0,*; 

else 

npwl streat (nuin2str (eont6.npwl) ,*,*); 

end 

if strcmp(cont6.ns)cipt,’empty’) »» 1 
nskipt = *1,*; 

else 

nskipt « streat(nuin2str(eont6.nskipt), 

end 

if strcmp(cont6.ns1cipx,’eirpty*) 1 

nskipx = *1,’; 

else 

nskipx * streat(num2str(cont6.nskipx),’,’); 

end 

if stremp(eont6.1popt,’empty*) ■=* 1 
Ipopt ■ *0,*; 

else 

Ipopt * streat (n\am2str (cont6. Ipopt),’,’); 

end 

if strcnpCconte.icopt,’enpty’) «- 1 
icopt * * 0,’; 

else 

icopt * streat (nuin2str(cont6.icopt) ,*,’); 

end 

if strcnp(cont6.iafopt,’eiTpty*) «* 1 
mfopt *» ’0, *; 

else 

mfopt » streat(num2str(cont6.mfopt),*,*); 

end 

if stremp(cont6.nodun^,’empty’) -* 1 
nodunp ■ * 0,’; 

else 

nodunp * streat (nuin2str (cont6.nodi3mp); 

end 

if stremp(cont6.idtail,’empty') 1 

idtail « ’0,’; 

else 

idtail = streat(num2str(cont6.idtail),’,’); 

end 

if stremp(cont6.idtll,’empty’) »* 1 
idtll « ’O’; 

else 

idtll « num2str(cont6.idtll); 

end 

entry « 

streat (nout, npchan,npgap, nprod,npehf,npwl,nskipt, nskipx, Ipopt, icopt,mfopt, nodump, idtail, i 
dtll); 

count * fprintf(fid,*%s \n',entry); 
function gen_cont7(fid,cont7) 
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if strcinp(cont7,t2aax,'empty') — 1 
tmax = '100.0, 

else 

tmax * sprintf('%7.4f,',cont7.tmax) ; 

end 

if strcit5>{cont7,tprint,'empty*) == 1 
tprint - *,'; 

else 

tprint *= sprint f (* % 7.4 f, ', cont7. tprint) ; 

end 

if strong (cent7.dumpt,'empty') *= 1 
dvm^t = ',' ; 

else 

duxi^t *= sprintf {'%7.4f, ' ,cont7.dumpt) ; 

end 

if stremp(cont7.tlplot,'empty') == 1 
tlplot = *,'; 

else 

tlplot = sprintf(*%7.4f,cont7.tlplot); 

end 

if strcmp(cont7.tfiche,'empty') 1 

tfiche “ *,*; 

else 

tfiche « sprintf{'%7.4f,',cont7.tfiche); 

end 

if stremp(cont7.tpdump,'empty *) -«1 
tpdump = *'; 

else 

tpduitp = sprintf ('%7.4f*,cont7.tpdump); 

end 

entry = street(tmax,tprint,dumpt,tlplot,tfiche,tpdump); 
count * fprintf(fid,'%s \n',entry); 

function gen__yipre__ending (fid) 

count = fprintf(fid,'endd \n'); 
count = fprintf(fid,'0'); 
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Vipre Execution Coordination 

Once the input data is extracted and encoded into a valid input file, it is time to start 
a vipre run. The following function performs diis task. The name, ‘vipre_runJon.m’ is 
indicitive of the version of VPRE that was in use - a version we called ‘jon_vipre’. 

The basic structure is to copy the input file to die directory where the VIPRE 
executable resides. The mex-function ‘callJon_vipre’ causes VIPRE to be initiated with 
die given input file. The resultant files are copied to the original working directory wiiere 
they are processed by the ‘parse_output_sv4_trans.m’ script. The VIPRE directory is 
cleaned of the used files. 


function vipre_run_jon (inputfile,var_file) 

outdirectory * pwd; 
current^dir = pwd; 

copyfilednputfile, ’c:\inatlab_svl3\bin\vipre\input .txt*); 
%transfer control to the vipre directory 
cd( *c:\nLatlab_svl3\bin\vipre’); 

%ensur€ that I have access to the callVipre.dll 
addpath(* c:\matlab_svl3\bin\vipre *); 

%€xecute the system call 
call_j on^vipre; 

%now delete the files 
% ’Vipre completed, collecting data’ 
if exist(’restout.txt*) 
delete(* restout.txt’); 
end 

delete(’input.txt ’); 
delete(’calcmp’); 
delete(* fiche *); 
delete(’rasp*); 
delete(’scrac*); 

%copy the useful files 

copyfile(* chfdat,txt’ , strcat(outdirectory/’\’/* chfdat.txt’)); 

copyfile(’chsum.txt’/strcat(outdirectory,’\’,’chsum.txt')); 

copyfile(’celldat.txt *, strcat(outdirectory,’\*,* celldat,txt’)); 

copyfile(’hotchnl.txt’, strcat(outdirectory,’hotchnl.txt’)); 

copyf ile(’fuelthr.txt*,strcat(outdirectory,’fuelthr.txt’)); 

%delete the left-over files 

delete (’ chsuiti. txt *) ; 

delete('chfdat.txt *); 

delete(’outptt.txt’); 

delete(* chfdmp.txt’); 

delete(’celldat.txt’); 

delete(’hotchnl.txt’); 

delete(’fuelthr.txt'); 

delete('restout *); 

cd(current_dir); 

parse_output_sv4_trans; 

%’Data Collected and Parsed’ 
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Output Data Parsing 


As shown in the previom section, once VIPRE is through running, &e data files are 
copied to the Matlab working directory. Here they are parsed. The data files generated 
by the VIPRE executable that are intended for further processing by the Matlab-VIPRE 
Interface are simply ASCII-formatted files filled with space-delimited numbers. The 
structure of these numbers is known based on the modifications made to the VIPRE 
source-code. The output data parsing functions exist to arrange this output data into 
Matlab-type arrays that are easy for the programmer to recognize and access. 

This particular function is, admittedly rather fragile in that it must be modified 
manually in the event that there are expected changes to the structure of the output data. 
Examples of this situation include: Changes to the number of rods, channels, gaps, 
transient time steps, number of CHF correlations to be used, and number of axial zones to 
ddp between data outputs. 

The source code is provided here: 


%parse_output_sv4_trans.m 

%some data needed to parse the output files: 

NDM_TIME_STEPS = 272; 

NUM_CHANNELS = 20; 

NUM_AXIAL_NODES = 97; 

%KUM_CHF_COKR is eliminated for transient calculations. There will be the option for 
only one. 

%KUM_CHF_CORR = 1; 

NUM_RODS = 24; 

%CHF_DATA_COLUMNS =12; 

%CK_SUM_DATA_COLUMS =7; %will leave out the first column — the channel numbers since 
they are 

%numbered consecutively 

NUM_AXIAL__DATA = ceil (NDM_AXIAL_NODES/2); %based on one observation — may need revision 

load chfdat.txt; 
load chsum.txt; 
load celldat.txt; 
load hotchnl.txt; 

%ioad fuelthr.txt;<- only used when there is a fuel model - not used for dummy rods 
%process this file first 

axial_ 2 one_bottom = chfdat(1:NUM_AXIAL_DATA,1); %this is ok for the transient case ~ 
numbers 

axial_zone_top = chfdat (1:NUM_AXIAL__DATA, 1); %don*t change 
%only need once, since it is the same for every channel 
%sr=sr«s:sr=*asr5s==rsssrrrsr:==srsr*=r«ssss:initiaii2e data 

channel_dnbr = zeros (NUM TIME STEPS,NUM_AXIAL_DATA,NUM_CHANNELS) ; 

Channel_rod__nuinber = zeros (NDM_TIME_STEPS,NUM_AXIAL_DATA,NUM_CHANNELS) ; 

channel_surface_hf = channel_dnbr; 

channel_chf = channel_dnbr; 

channel_uniform_chf = channel_dnbr; 

channel_axial_flux_factor = channel_dnbr; 

channel_grid_factor = channel_dnbr; 

channel_unheated_wall__f actor = channel_dnbr; 

channeljcoass^velocity = channel_dnbr; 
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charmel_teir5> * zeros (KUM_CHANNELS, 1) ; 
channel_enthalpy « charmel_ten^p; 
channel_density » channel^temp; 
channel_quality * chamiel_teinp; 
channel^void^fraction « channel^tenp; 
channel_£low_rate ■ channel^tenqp; 
chaiineljnass^flux ■ channel^ten^s; 

initialize ACW datS ic==g = ^g =g=«== = ^== 
channel_distance = zeros (NUM_TIME_STEPS,NDM_AXIAL_DATA+1,NDM_CHANNELS) ; 
channel_deltajp_local • channel_distance; 
cbannel_flowrate_local * channeled!stance; 
channel_velocity_local - channel^distance; 
channeljnass_£lux_local_local • channeled!stance; 

%skip one row for channel distance — this shouldn*t have been saved... but 
%oh well,,,. 

channel_density_local * channel_distance; 
channel_enthalpy_local * channel_distance; 
channel_void_£raction_local « channeled!stance; 
channel_quality_local « channeled!stance; 
chann€l_ten^_local « channeled!stance; 
channel_linear_heat_rate_local « channel_distance; 

%3ag! = «g sg 3sgg3a «aarg ar-p=ga:ggtt ChanOel data e5=5==52a=ss=s===s=s====s!=s====at= 

corrjadnbr * zeros (NUM_TIME_STEPS, 1); 
corr_hot_channel « corrjndi£r; 
corr_hot_rod ® corrjndnbr; 
corr_indnbr_axial_^level * corr^mdnbr; 
corr_mdnbr_eq_quality « corrjndnbr; 
corr_a>dnbrJheat_flux • corr__indnbr; 
corrjiidnbr_chf * corrjndnbr; 
transient_time * corrjndnbr; 

Fuel Thermal Data 

rod_hx_CO€ff « zeros {NUM_TIME_STEPS,NUM_AXIAL_DATA,NDM_RODS) ; 

rod_clad_teit^_out ■ rod_^hx_coeff; 

rod_clad_teii55~ave - rod^hx^coeff; 

rod_clad_temp_in ■ rod_hx_coeff; 

rod_gap_cond “ rod_hx^coeff; 

rod_fuel_teitq?_out « r^_hx_coeff; 

rod_fuel_ten^_ave « rod_hx^coeff; 

rod_fuel_ten^_cl » rod_hx_coeff; 

indexestart * 1; 

for Ch » 1:NUM_TIME_STEPS 

corr_mdnbrTch) « hotchnl(ch,6); 

corr_hot_channe1(ch) = hotchnl(ch,7); 

corr_hot_rod(ch) « hotchnl(ch,8); 

corrjadnbr_axial_level(ch) * hotchnl(ch,9); 

corrjndnbr_eq_quality(ch) - hotchnl(ch,11); 

corrjndnbr^heat^flux(ch) « hotchnl(ch,12); 

CO rr jadnbr_chf(ch) » hotchnl(ch,13); 
transient_time(ch) - hotchnl(ch,14) ; 
for j * 1:NDM_CHANNELS 

index_end - index_start + NUM_AXIAL_DATA-1; 
channel^dnbr(ch,;,j) • chfdat(index_start:index_end,3); 
channel"rod_nuinber (ch,;, j) « chfdat (indexestartTindex_end, 4); 
channel_surface_hf(ch,:,j) ■ chfdat(indexestart:index_end,5); 
channel_chf(ch, j, j) « chfdat(index_start:index_end,6); 
channel_uniform_chf(ch,:,j) » chfdat(index_start:index_end,7); 
channel_axial_flux_factor(ch,;,j) ■ chfdat(indexestart:index_end,8); 
channel_grid_factor(ch,:,j) • chfdat{index_start:index_end,9); 
channel_unheated_wall_factor(ch, :, j) * chfdat(indexestart:index_end,10); 
channeljnass_velocity(ch,;,j) * chfdat(indexestart:index_end,11); 
channel_equilibrium_guality(ch,:,j) « chfdat(indexestart:index_end,12); 
index^start * index^start + NUM_AXIAL_DATA; %increment down to the next set of 
channel data * 

end 






end 


indexestart = 1; 
for ts = 1:NUM_TIME_STEPS 
for j = 1:NUM_CHANNELS 

index_end = index_start + NUM_AXIAL_DATA; %allows for one extra row compared to 
above code 

channel_distance(ts,:,j) = celldat(index_start:index_end,1); 
channel_deltajp_local(ts,j) = celldat{index_start:index_end,2); 
channel_flowrate_local(ts,:,j) = celldat(index_start:index_end,3); 
channel_velocity_local(ts,:,j) = celldat(index_start:index_end,4); 
channel_mass_flux_local_local (ts,:, j) = celldat (indexestart: index^end, 5); 

%skip one row for channel distance — this shouldn't have been saved.., but 
%oh well.... 

channel_density_local(ts,:,j) = celldat(index_start:index_end,7); 
channel_enthalpy_local(ts,:, j) = celldat (index_^start:index_end,8) ; 
channel_void_fraction__local(ts,:,j) = celldat(index_start:index_end,9); 
channel_quality_local(ts,:,j) = celldat(index_start:index_end,10); 
channel_temp_local(ts,:,j) * celldat(index_start:index_end,11); 
channel_linear_heat_rate_local(ts,:,j) = celldat(index_start:index_end,12); 
index^start = index_end +1; 

end 

end 

This section is commented-out because it is only used for runs where there exists a fuel 
rod model. For 'dummy' rods, this data is not generated or collected. 

%index__start - 1? 

%for ts = IrlWM^TIME^STEPS 
% for j - l:NCM_RODS 

% index__end « indexes tart + NUM_AXIAL_DATA--1; 

% rod_hx_coeff (ts,:, j) = fuelthr (index__start:index_end, 1); 

% rod2clad_temp_out (ts,;, j) * fuelthr (index_start: index__end, 2); 

% rod_clad__temp_ave (ts,:, j) = fuelthr (index_start :index_end, 3); 

% rod_ciad_teinp_in(ts,;, j) *= fuelthr (index_start;index_end, 4); 

% rod_gap__cond(ts,:, j) = fuelthr (iridex__start:index_end, 5); 

% rod__fuel_temp_out (ts,:, j) = fuelthr (index_start :index__end, 6); 

% rod_fuel_temp_ave(ts,:,j) - fuelthr(index_start:index_end,7); 

% rod__fuel__temp_cl (ts,;, j) - fuelthr (index_start:index_end, 8); 

% indexestart « index_end +1; 

% end 

%end 

channel_enthalpy = chsum(:, 2); 
channel_temp - chsum {:, 3); 
channel_density = chsum(:,4); 
channel_guality *= chsum (:, 5); 
channel__void_fraction = chsum (:, 6) ; 
channel_flow^rate = chsum (:, 7); 
channel_mass_flux = chsum{:, 8) ; 

clear chfdat; 
clear chsum; 
clear celldat; 
clear hotchnl; 

%clear fuelthr; 

save channel_data; %save the remaining data to a file so that it may be re-loaded later 
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Modifications to VIPRE 


Several modifications to the VIPRE source code were required in order to allow for 
tile script-interface.*^ Some of tiie changes were merely for convenience - such as 
qiecifying tiiat the input file should be named “input.txt” instead of simply “input”.* 

Other changes were absolutely essential — re-dimensioning the data arrays to allow for 
more than 10 time-steps. 

Additional Output Files 

In order to allow for the scripted interface, it was desirable to obtain the normal 
program output data in a form more easily processed by tiie script interface. In particular, 
it is inconvenient (at least for a Matlab-based script interface) to have text interspersed 
with numeric data. There are no simple, high-level Matlab commands that deal 
effectively with the mixture of text and numerics in a file. On the otiier hand, it is a 
trivial task to load a file into the Matlab workspace that is space or tab-delimited 
numbers™. 

The most important principle guiding the modifications to the VIPRE source code 
was; DO NOT CHANGE THE CODE OUTPUT. Meaning that I did not want to do 
anything to tiie code that would alter or eliminate the normal output file (or tiie 
information that would go there...). To prevent changing the ouqiut file, additional files 
were created to hold the purely numeric data that was desired. 

In VIPRE.FOR, the following integer variables were defined. 

istul = 18 
istu2 = 14 
istu3 = 15 
istu4 = 16 
istuS = 17 


The script interfece could possibly have been created widiout modifying flie program source code, but it 
would have been much more difScult to process the program output. 

* This is an interestmg arti&ct of the Windows operating ^stem. It is actually rather difficuh to create an 
ASCn-text file without ^ipending die ‘.txt’ suffix. The programs MS Wordpad and MS Notepad both do it 
automatically. It is possftle to use the MS Edit program ficm tiie command prompt to make input files, but 
the added functionality of the odier programs is lost. The easin alternative was to maike the trivial change 
to die source code to ilow iiqjut files with die ‘.txt’ suffix. 

“ The command is simply ‘load (filename)” or “load filename. All of die numeric data is assigned to a 
Matlab array named^/ennme. 





These variables were used as file descriptors for the additional ou^ut files that were 
created. 

<q)en(umt=istul,file=’chsuin.txt'^tus='new',fonn-formatted') 
open(unit=istu2,file='difdat.txt',status-new’,form-formatted') 
open(unit=istu3,file='celldatt3Ct',status-new',form='formatted') 
opeii(uni^stu4,file=T»otchnl.txf,status='new',form-formatted') 
opeii(imit=istu5,file=^fuelthr.txt',status-neAv',form-formatted') 

The corresponding code to print the output to these files is found in the subroutine 
‘result’in VIPRE3.FOR. 

c STU ADDED OUTPUT ♦♦♦♦'•‘****************************** 
write(stul,10115) i4i(i^d3qpl),tdum4-ho(i^dxpl), 

1 qlty,al^^i^(bq)l),fluxd 

c STU ADDED OUTPUT ♦*♦******♦♦*****♦****♦*********♦**♦ 

10115 format(10x,i4^x410.2,4x,fl0.2,5x,®.3,lx, 

1 ©.3,7K,©.4,lx,fll.3,lx,fl0.4) 

write(stu2,10262) xduml^dum2,chfr(ij)^,sfhix, 

1 cch^dflux,fexl(ij),fgrid(ij),fwal(ij),gpoc 

10262 formate lx,flS. l,flS. 1 ^x,fiS.3, Ix,i3,3x,lx,f7.4,3x,f7.4, 

1 5x,f7.4^x,lx,ffi.4^x,ffi.4^x,ffi.4,6x3x,f7.4, 

2 9x,f7.4) 

write(stu4,10277) kase,prefhavg,gavg,qave,smdnbr,ihot 4 ihot,xhot, 

1 ^otpcx,qmeas,qpred,etime 

10277 format(lx,i3,3x,flS.l,lx,f7.2,5x,fl5.3,5x,f8.3,3x, 

1 fi5.3^x,i33x9i3,lx,f6.1^2x,f6.3^x,f6.3,4x,f6.3,5x, 

2 f6.3,6x,f8.3) 

write(stu3,10296) xx,pres,fl[ii jj),u,g, 

1 xxl4lK)(iijj)di(iiJ}),alfej(iiJj),qualij, 

3 tchflS^iijjXqprimt 

10296 format(2x,fl5. I^f7.2,lx,fl 1.3^x,f7.2,3x,f8.3,4x, 

1 2x,f6.2,3x,f6.2,4x,f6.1,5x,f6.4,4x,f6.4,5x,f6.1, 

3 lx,fl4.4) 

\vrite(stu5,10407)htcd,trod(nclad^x),tavc,trod(nclad-l^x), 

1 gpcdum,trod(iifuel^jx),tavftrodcl 


10407 foimat(lx,fl5.Ux,3(f6.i;2x),fl2.3^x,3(2x,fi5.1)) 


These statements were placed coincidentally with the analogous outputs to the 
normal output file (outputtxt). It was natural to organize the changes this way. Each 
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output file was a rectangular array of numbers that Matlab would load into it’s 
environment in one step,” 

Time Step Tracking 

Also placed in VIPRE.FOR was a trivial, but useful change to allow tracking of 
transient progression. At the end of every time step, VIPRE would print out die number 
of die time step that it was working on. This is comforting in the event diat one is 
running a very long transient and one wants to know how things are going. More likely, 
one has an input file for a transient that continues to crash, it is a good diagnostic aid to 
know what time step was last processed before the program terminated. 

In VIPRE.FOR, in the code just as the current time-step is complete, the following 
code is executed: 

ifl[stu_aiit .gL llwritef*,10151) stu_cnt-l 
10151 foni^lx,Tiine step ',15,' complete.') 
stu_ait = stujcnt + 1 

Here, ‘stu cnt’ is simply an integer that is initialized to zero. 

Increase Maximum Number of Time Steps 

In its initial condition VIPRE was capable of processing only 10 transient time steps. 
Since all of the transients considered in this thesis were temporally discretized into 402 
time steps, a change was required. 

While, for this project, this modification was performed manually, there is a tool that 
has been developed specifically for tiiis purpose. The program is called SPECSET. This 
is a program, that takes as input a text file called ‘Specs’ which is listed here: 

♦ADDCOMD SPECS 
ia=3 
ib=3 
ie=60 
. ip=2 
jf=5 


* Incidentally, die numbers in the output file to be read by die Matlab interface must be strictly two- 
dimensional. By this it ismeant diat if diere are six qiace-delimited numbers in die first row, diere must be 
six numbers in every row. This is why there are several added ou^ut files radier dian only one. 
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mc=530 

mf=500 

ing=915 

im=10 

mk=5 

mn=16 

mp=50 

mr=500 

mt=10 

inx=160 

na=5 

mn=8 

lg=l 

lx=l 

lj=l 

lh=l 

mv=2 

m\v=530 

m2?=15 

c 

cend “ last co mmo n 

Each line is interpreted by SPECSET as a variable parameter. The me aning of each 
variable is given in reference [48]. Once SPECSET is run, a second program, called 
“UPDATE” is run. This regenerates the common blocks of the VIPRE code so that the 
statically allocated arrays are set to be of the correct size. The source code of VIPRE is 
then manually ipdated with these new common blocks and re-compiled. 
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Extension of Matlab-VIPRE Interface to A Parallel Distributed 
Computing Environment 

The development of a script-based interface and script-based coupling of multiple 
codes allows for relatively simple creation of fairly computationally demanding tasks. 

The Monte Carlo Uncertainty Procedure (MCUP), described fully in Chapter 3 of this 
thesis, requires many hours of computational time on even the most modem personal 
computers. For example, a siiigle VIPRE transient analysis data point for the purposes of 
the Monte Carlo Uncertainty Procedure reqmres ^proximately 51 seconds.® The 2000 
samples normally required for this procedure would thus consume slightly more than 28 
hours of computer time. 

Fortunately, the computational tasks that are required for the MCUP are highly 
parallelizable*’ and can thus benefit fi'om the proliferation of computer ‘clusters’ built 
from commodity components. At the time of this writing, there are at least 14 clusters in 
operation at MIT including one 30-node machine within the Nuclear Engineering 
Department. 

The purpose of this section is to provide a set of recommendations regarding tire 
migration of the existing script-interface to a parallel computer environment. \\^th 
judicious choice of software tools and parallel progr amming environments, tiie resulting 
package can be scalable to as large a cluster as is desired, and portable from one machine 
to the next These recommendatioiis are relevant for the VIPRE interface. The 
recommendations are as follows; 

• Port VIPRE to the Linux environment. This assumes that tiie target cluster 
m ac hine uses Linux as its operatii^ system. Typically this is the case, since 
Linux is finely available. 

• Re-write the script interface using standard, free, Linux software components. 
Probably the quickest route would be, to use a free spreadsheet too such as 
Gnumeric to hold the input data, and a scripting language such as Perl to form tiie 
core of the interface. 


® A personal computer wifli a 1.8 GHz Pentium W processor was used for diese computations. 

** For die MCUP, no communication is required between successive sample runs. In the parlance of the 
parallel programming community, the procedure is ‘Embarrassingly Parcel’ because it is so ea^ to 
paralleli^ die algorithm. 
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• Perl is recommended for die interface language as it has an interface to MPI, a 
standard parallel progr ammin g library, and an interface to Gnumeric to allow for 
extraction of the input data. 

• The basic architecture of the interface need not change, only the components used 
to create each part 

This short appendix is meant to serve as a roadmap for others who may be interested 
in implementing such a tool. The coarse grained parallelism that exists in analysis 
involving die Matiab-VIPRE Interface could be exploited by relatively low-cost parallel 
platforms. This capability could make the more computationally demanding optimization 
and uncertainty analysis more realistic for routine studies. 
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Appendix 3 AECL-UO Look-up Table Interface 


The AECL-UO Look-up table had been provided from the University of Ottawa for 
to allow students in MIT course 22.312 to more easily make use of this correlation.^^^^ 
The table was provided in the form of a FORTRAN 77 program where the user could 
place, in the source code, the plant conditions from which to compute the correlation 
estimated CHF. Desiring the ability to quickly and conveniently access this functionality 
from within a Matlab environment, a set of functions was authored to allow this access. 

The basic operation of this interface is: 

A wrapper frmctin calls a mex-file Aat passes the required arguments to a modified 
FORTRAN subroutine that performs the same task tiiat the original program did. The 
FORTRAN subroutine writes the result to an ASCII text file, which is then read by the 
wrapper function and passed back to the Matlab workspace. The text file is then deleted. 

A schematic representation of this interface is provided in Figure 43. 



Figure 43:Scliematic Representation of Matlab - AECL-UO Inteface. 
The modified portions of the look-up table source code is provided here: 
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OPEN (UNIT=1, FILE='CHF„TEST.DAr) 
CALL CHF_LUT(D J>,G AQCHF) 
G_CHF = QCHF 
WRITE (1,1) P,G,X,QCHF 
1 FORMAT (8E12.4) 

CLOSE(l) 


END 

The wrapper script - that is, the script that the user actually calls - is given here: 

%grcev_lu.xn 

function chf = gorev_lu{D,P,G,X) 

addpath(* C:\matiab_svl3\work\Research\CHF_CORR\Groeneveld’); 

G_L0_TAB(D,P,G,X); 

load(* CHF_TEST.DAT’); 

chf « CHF_TEST; 

delete(* CHF_TEST.DAT M 


The remainder of die code is submitted electronically. 

It is notable that this look-up function runs fairly slowly due to the requirement to 
communicate the result through the file system.® When many hundreds, or many 
thousands of consecutive evaluations would be required, the performance penally is quite 
burdensome. In the case where the function is called relatively infirequently, the poor 
performance is not noticeable. 


• Le. by writing the result to the file, then reading the file. 
I.e. less than one hundred times in a row. 
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Appendix 4 IRIS Open Matlab-VIpre Scripts 

The following is a collection of high-level scripts used to perform larger, higher- 
level tasks. These scripts are meant as a guide to any future users of this interface to help 
them cobble together larger, useful scripts from the lower-level scripts presented before. 

Steady State Analysis 

A simple script for performing a steady-state analysis of the IRIS Open core is 
provided here. For this example, the W-3L correlation is used. Note that the structure of 
this script follows the logical pattern of: Extract input data from Excel, generate the input 
file, instantiate vipre, parse and store the outputs. 


SPREADSHEET_NAME = *17xl7_trans_lrss_w31.xls’/ 

%provide access to low-level tools. 

addpath(*c:\matlab_svl3\work\research\vipre transient tools *); 
%identify and get handles to input spreadsheets 
spreadsheet_filename = streat(pwd,’\,SPREADSHEET_NAME); 

[xl,spread_sheet] = get_spreadsheet(spreadsheet_filename); 
input_sheet = get_worksheet(spread_sheet,‘input-nom-duinmy*); 

%obtain input data and generate initial input file 
input_file_naiae = *input_w31'; 
var_file_name = *var_w31*; 

get_excel_input2_w31 (input_sheet,var_file_naine); 
generate_input_file (input_file_naine, var_file_name); 

%close the connection to the excel spreadsheet and clean up 
invoke(spread_sheet,* Save *); 

invoke(spread_sheet,‘Close*); %close the file that I was working with 
delete (xl) ;%delete the activex ser^'er object 
vipre_run_j on (input^f ile^name, var_f ile^name); 


The last few steps of the pattern are all carried out by the script vipre_runJon.m. 
Note that fiiere are many scripts with names starting with “vipre_run_....” There are 
several variants because there were several versions of the Matlab-VIPRE interface - 
specifically, different versions of the VIPRE code to deal with. Different versions of the 
“vipre_run..” scripts were written to deal with those differences. The names are all 
different, but their functionality is the same. 


Sensitivity Analysis 

Correlation sensitivity was computed using two different methodologies. The first 
methodology focused on the degree to which the sensitivity of a given CHF correlation in 
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response to changes in a given parameter varied over a relatively large range in parameter 
value. As an example, the sensitivity of the W-3L correlation to changes in mass flxix is 

computed for mass fluxes in the range of 1.2533 ± 

/ft -sec 

The second methodology is used to illustrate that die sensitivity of a correlation to 
changes in a given parameter is a iimction of more tiian just the parameter itself. Rather, 
the state of other plant parameters has an influence as well. For example, the sensitivity 
of die W-3L correlation to changes in mass flux is computed with all five uncertain 
parameters in different states. What is immediately apparent fi:om the result, is that the 
magnitude of die sensitivity can vaiy quite widely even though all of the uncertain 
parameters are fairly close to their nominal value. Further analysis reveals that the 
sensitivity is at it’s worst-case value when the plant is, in some sense, closest to DNB. 
This occurs when mass flux and system pressure are low and core inlet temperature, 
linear power and are high. 

These sensitivities were computed with the using the Matlab-Vipre Interface 
described in chapter 2 of this thesis. This interface greatly simplified die analysis by 
reducing the tedium involved in performing the calculation. In the case of the second 
methodology, the process involved several thousand VIPRE runs. The second 
methodology would be almost completely impractical to perform in the absence of the 
Matlab-Vipre Interface. 

The code for die first example is given here: 

%find_sensitivity.ro 

%coinputes the W-3L sensitivity to fluctuations in Mass Flow Rate. 

PARAM MIN « ,99; 

PARAM^MAX - 1.01; 

NOM_PARAM * 1.2533; 

FIELD * *oper5.gin*; 

NUM_STEPS - 3; 

spreadsheet_filenaroe « strcat(pwd,»W*lRlS-refined VIPRE core inodel~17xl7-np.xlsM; 
addpath(’c:\inatlabrl2\wor)c\research\matlab vipre tools’); %add interface to workspace 
PARAM_SPACE - linspace (PARAM_MIN, PARAM_MAX, NDM STEPS); 

PARAM_SPACE « NC»d_PARAM .♦ PARAM__SPACE; %get the set of new values 

%open the excel file 

[xl,spread_sheetl “ get_spreadsheet(spreadsheet_filename); 
input^sheet « get_worksheet(spread_sheet,’input-nom-dummy*); 
file_root ■ ’flow"**; 
i - 1; 

input_file_naiae « strcat (file_root,num2str (i)); 
var_filejname * strcat (file^root, '_var * ,nuin2str (i)); 








get_excel_input2_w3L (input^sheet, var_file_name) ; 

%exc€l input has been sav’ed, excel activex object is no longer necessary 
invoke (spread_sheet, * Save'); 

invoke(spread_sheet,’Close*); %close the file that I was working with 
delete(xl);%dsiete the activex server object 

%perfonn the runs 
for i = 1:NUM_STEPS 

change^input (var_file_naine, FIELD, PARAM_SPACE (i)) ; 
generate_input_file (input__file_name,var_file_name); 
vipre_run_sens (input_file_naine); 
input_file_name - strcat (file_root,nuin2str (i+1)); 


end 

%clean up temporary files 
for i = 1;NUM_STEPS 

delete(strcat(’flow’,num2str(i))); 

end 

delete (strcat (var_fil€_name, * .mat *)); 

%coliect the required data 
mdnbr * zeros (NtJM_STEPS, 1) ; 
for i = 1:NUM__STEPS 

direc = strcat(file_root,num2str(i),’-out’); 

cd(direc); 

load channel_data; 

mdnbr(i) « corr_mdnbr; 

cd .. 

end 


ave_mdnbr == mean (mdnbr); %defined as the nominal MDNBR for this case — this works ok 

%since the variation in MDNBR has been shown by computational experiment to be 

%very nearly linear over a 1% perturbation in parameter range (at least for temperature) 

percent_varjmdnbr = {(max (mdnbr) - min (mdnbr))/avejmdnbr) * 100; 

percent_var_parameter = (PARAM_MAX - PARAM_MIN) * 100; 

sensitivity » percent_var_mdnbr/percent_varjparameter; 


Code for the second methodology is provided here. The driver script is: 


%sensitivity.m 

mass^flux = [1-1906,1-25326,1.3159]; 
lin_power [2.9792,3.04,3.1]; 
inlet^ten?) = [553.6,557.6,561.6]; 
systemjpressure = [2230,2259.39,2290]; 
f_dh_e = [1.0,1.02,1.04]; 

%generat€ permutation matrices 
index = 1; 
for m = 1:3 

for 1 1:3 

for i *= 1:3 

for s = 1:3 

for f = 1:3 

perm_list(index,:) « [m,l,i,s,f]; 
index * index +1; 

end 

end 

end 

end 

end 
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[num_permutes,nl “ size(penn^list); 

%this permutation list will have to be cycled through 5 times 

%at each cycle, I will take the sensitivity with respect to a different parameter 
sensitivity_array « zeros(numjpermutes,5); 

spreadsheet_filename = street (pwd, *»IRIS-refined VIPRE core model-17xl7-np.xls'); 
addpathCc:\niatlabrl2\work\research\matlab vipre tools’); 


%open the excel file 

lxl,spread_sheet] - get_spreadsheet(spreadsheet_filename); 
input_sheet * get_worksheet(spread_sheet,’input-nom-dummy*); 
file^root *= * flow'; 
i *= 1; 

input_file_name * streat (file_root,nuin2str (i)); 
var_file_naiiie ■ streat (file_root, *_var * ,num2str (i)); 
get_excel_input2_w3L (input_sheet, var_f ile^name); 

%excel input has been saved^ excel activex object is no longer necessary 
invoke(spread_sheet, * Save’)/ 

invoke(spread_sheet,’Close*); %close the file that I was working with 
delete(xl);%delete the activex server object 

%now all of the pieces are in place — start with mass flux 

old_value * 1,0; %for change_f_clh_e.m — using nominal inputs -> the existing value is 
1.0 

index « 0; 

mass_flux_sensitivity; 
linearjpower_sensitivity; 
inlet_ten^erature_sensitivity; 
system__pressure_sensitivity; 
f_dh_e_s ensitivity; 


Notice, here at the end, five scripts are called to get the sensitivity of the correlation 
with respect to mass flux, linear power, etc... These scripts are nearly identical, the 
mass_flux_sensitivity script is provided for illustration: 

%mass_flux_sensitivity.jn 

for i « Irnum^ermutes 
index « index + 1; 

sprintf(’Commencing Run # %d’,index) 

PARAM_MIN = .99/ 

PARAM_MAX = 1.01; 

NOM_PARAM « mass_flux (penn^list (i, 1)); 

FIELD ■ ’operS.gin*; 

MDM_STEPS - 3; 

PARAM_SPACE * linspace (PARAM_MIN, PARAM_MAX, NUM STEPS); 

PARAM_SPACE * NOM^PARAM .* PARAM^SPACE; %get the set of new values 
^change the other parameters 

change_input (var_file^name, *operS .pwrinp’, lin^power (perm_list (i, 2))); 
change^input (var~file“name, ’ operS .hin’, inlet_ten^ (perm^list (i, 3))) ; 
change_input (var_file_naine, 'operS.pref', system^pressure (perm_list (i,4))); 
change_f_dh_e (var_file^name, oldjvalue, f_dh_e {perm^list (1,5))); 
old_value * f_dh_e (perm__list (i,5)); %update this number for future use 

ten^jDadnbr » zeros (NUM^STEPS, 1); %storage of the mdnbr results for each run in 
%the sensitivity analysis 

for j - 1:NUM_STEPS 

change_input (var_file_name, FIELD, PARAMOS PACE (j)) ; 
generate_input_f ile <input_file_name, var__file_name); 
vipre_run_stu_jacl (input_file n^e,var_file_name); 





load mdnbr_dat; 
temp_iadnbr(j) = corr_mdnbr; 
end 

ave_mdnbr = mean (temp_mdnbr); %defined as the nominal MDNBR for this case — this 
works ok 

%since the variation in MDKBR has been shown by computational experiment to be 
%very nearly linear over a 1% perturbation in parameter range (at least for 
temperature) 

percent_var_mdnbr = ((inax (temp_mdnbr) - min(temp_mdnbr))/ave_mdnbr) * 100; 

percent_var_j5arameter = (PARAM_MAX - PARAM^MIN) * 100; 

sensitivity = percent_var_mdnbr/percent_var_parameter; 
sensitivity_array(i, 1) *= sensitivity; %store this in the array 

end 


Transient Analysis 

An example script for a single transient simulation run is provided here. 


% s ingl e_t r an s_r un___w31. m 

SPREADSHEET_NAME = '17xl7_trans_lrss_w31.xls’; 

%provide access to low-level tools. 

addpath(’c:\matlab_svl3\work\research\vipre transient tools’); 
%identify and get handles to input spreadsheets 
spreadsheet_f ilename = strcat (pwd, »\ *, SPREADSHEET_NAME); 

[xl,spread_sheet] = get_spreadsheet(spreadsheet_filename); 
input_sheet = get_worksheet(spread_sheet,'input-nom-dummy_trans*); 
transient_sheet = get_worksheet (spread_sheet, »trans__input *); 

%obtain input data and generate initial input file 
input_file_name = *input_w31*; 
var__file_name « *var_w31*; 

get_excel_input2_trans_w31 (input_sheet, transient_sheet, var_file_name) ; 
generate_input_file_trans (input_file_name, var_file_name); 

%close the connection to the excel spreadsheet and clean up 
invoke (spread__sheet, * Save *); 

invoke(spread_sheet/^Close*); %close the file that I was working with 
delete(xl);%delete the activex server object 
vipre_runJ on (input_f ile_name, var_file_name); 


Monte Carlo Uncertainty Analysis 

The basic procedure for performing the Monte Carlo Uncertainty Procedure (MCUP) 
is outlined in Chapter 3. This appendix will provide a sample of the Matlab-VIPRE 
Interface scripts needed to accomplish this task. 

The presented script is for performing the MCUP for the PLOFA transient using the 
EPRICHF correlation. For this analysis, 4000 transient sample runs will be taken. Each 
uncertain parameter will be represented by a rectangular probability distribution. The 
results will be collected and then analyzed with a series of scripts. 
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The source code is given as follows 


%trans_mcjplof a_epri .m 

SPREADSHEET_NAME * * 17xl7_trans^lofa_epri .xls * ; 
NOM SAHPLES « 4000; 


Parameter Information «sssa:=sR==iaa=:=«sss=»=s««sss==sia=s=s£aaK»ass==ssas 


%this section includes the parameters to be sampled, along with their statistical 
%distribution. I think to start, I will just employ a rectangular distribution 
%for all parameters. But this should be easily adjusted. 

inlet_temp - zeros (NUM_SAMPLES, 1) ; 
inlet_teii^_field * *oper5,hin*; 
system^pressure • zeros(NUM_SAMPLES,1); 
system^pressure field “'operS.pref'; 
massif lux - zeros (N0M_SAMPLES, 1) ; 
massiflux_field ■ *oper5.gin»; 
linear^power « zeros(NUM_SAMPLES,1); 
liiiear_power_field « 'operS.pwrinp*; 
f_dh_e « zeros(NDM_SAMPLES,1); 

%sR==istsi=iar==tssi==i:sis: DSta Atray a=»»=S^==a»=«*==—=i=-=^ss-=i=isis=;=L=a:==i=.=ai==;==s=!=i:===ssst:===£SS==£==s=sss 

mdnbr * zeros(NUM^SAMPLES,1); 


%a:atgsgggg'ararg:gggsgsgsgxrggggagarg’argsgrg=sg3ragagggagg'gr8g;s»gg^agggsigs»gggg;g«'a!'g'graggrag8agsr8gsssggggaggr8ga; i a.>^ g gg»^^;g^ 

Parameter Random Sample Generation 


Inlet Temperature 

%rectangular distribution at 557.6 +/- 10 degrees F 
NOMINAL^VALtrE - 557.6; 

LOWER_RANGE = 4; 

UPPER_RANGE * 4; 

%generate rectanular distribution about the nominal value 
inlet^teDp • (UPPER_RANGE + LOWER_RANGE) .* rand(NDM^SAMPLES, 1) + ... 
(NCWINAL^VAIUE - LOWER_RANGE); 

System Pressure 

NOMINAL_VALUE - 2259.39; 

LOWER_RANGE - 30; 

UPPER^RANGE - 30; 

%generate rectangular distribution about the nominal value 
system_pressure « (DPPER^RANGE + LCWER_RANGE) rand(iraM_SAMPLES,l) + ... 
(NOMINAL_VALDE - LOWER_RANGE>; 

%=rararsrsr=^==rar=rar»as=’^s?=ss»=ss*»=rMSS=r»=r=f»rar«r=:=srs:=f«=sa!=fss=r=»= 
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NOMINAL_VALUE = 1.25326; 

LOWER_RANGE = NOMINAL_VALUE*(.02); 

UPPER_RANGE = NOMINAL_VALUE *(.02); 

%generate rectangular distribution about the nominal value 
mass_flux ** (UPPER_RANGE + LOWER^RANGE) .* rand(NOM_SAMPLES,1) + ... 
(NOMINAL_VALUE - LOWER^RANGE); 


%s===:=:==:=s=^ Linear Power ========================== 

NOMINAL_VALUE = 3.040; 

LOWER_RANGE = NOMINAL_VALUE*{.02); 

UPPER_RANGE = NOMINAL_VALUE*{.02); 

%generate rectangular distribution about the nominal value 
linear_j>ower = (UPPER^RANGE + LOWER_RANGE) .* rand(NUM_SAMPLES,1) + ... 
(NOMINAL_VALUE - LOWER__RANGE) ; 


% =^i!==i^=±==:ssrssKSS3r s:i=i=£ss:=i=: =1====s=i=sssssKS5sssss;Ksssas:=sss: s SKLi 

%=========- F dH E =^^:==r========r=r==r==r==:=== 


NOMINAL_VALUE = 1.02; 

LOWER_RANGE = .02; 

UPPER_RANGE = .02; 

%generate rectangular distribution about the nominal value 
f_dh_e = (UPPER_RANGE + LOWER_RANGE) .* rand{N0M_SAMPLES,1) + ... 
(NOMINAL_VALUE - LOWER_RANGE); 


%=;===r==rrss;=r^=;:r=rsr:=r=rss====;=r=ssrs==;=r;s;ssss;sr=7=:sss;s=sr==rs=s;=;sr=;a; 

%^=:=^=======:=============================:======:=======: 

%=:===s=s;L=sa!ss=ssss===L==i=^^=====^siaa=:=sss=sss:=i==s=:s!i^S£=ss===s=:s======:=s:s:ri=:^=:ss^=i=is:s==i==sis==i=i===:=i==i=iz==i: 

%=======r=s==s=== Get Tools and Initialize Input ==========:===============:=========: 

%provide access to low-level tools, 

addpath(’c:\matlab_svl3\work\research\vipre transient tools'); 

%identify and'get handles to input spreadsheets 
spreadsheet_filename * strcat(pwd,’\’/SPREADSHEET_NAME); 

Ixl,spread_sheet] = get_spreadsheet(spreadsheet_filename); 

%set(xl,’Visible *,'False*); 

input_sheet - get_worksheet(spread_sheet,*input-nom-duinmy_trans*); 
transient_sheet = get_worksheet(spread_sheet,'trans_input'); 

%obtain input data and generate initial input file 

file_root = 'input'; 

input_file_naine = file_root; 

var_f ile_name = streat {f ile_root,' var'); 

get_excel_input2_trans_epri (input_sheet, transient_sheet^ var_file_name); 
gene rate_input_f ile_trans (input_f ile_name, var_f ile_name); 

%close the connection to the excel spreadsheet and clean up 
invoke(spread_sheet,'Save'); 

invoke(spread_sheet,'Close*); %close the file that I was working with 
delete(xl);%delete the activex server object 

%=====iz======i==: the Simulations ======================================== 


f ■ • 

I' 

I 
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for i * l:mJM_SAMPLES 

sprintf(*Comencing Simulation Run # %d*,i) 

if i — 1 

fdhe_old = 1; 
else 

fdhe_old - f_dh_e(i-l); 

end 

change^input (var_file_name, inlet_teinp_field, inlet_teii^ (i)); 
change_input (var_file_naine, 8ystem_pressure_field, system^pressure (i)); 
change_input(var_file_name,massiflux^field,mass_fl^lx(i)); 
change_input {var_file_name,linear_power_field,linearjpower (i)); 
change_fdhe (var_filejiame, fdhe_old, f^dh__e (i)); 
generate_input_file_trans (input_file_naine, var_file_name); 
vipre_run_sv5a_mc (input_file_name); 
load mdnbr_dat; 
mdnbr(i) * min(corr^mdnbr); 

end 

save run_dnb_data mdnbr; 

save san^le_data inlet_ten^ systemjpressure mass_flux linear^power f_dh_e; 


At &is point, the transient runs have all been made. The MDNBR results from each 
sample is saved to a file, as are the random samples of the parameters. 

The scripts to perform the data analysis are provided here: 

%data analysis 

TOTAL_RUNS * 4000; %total number of runs to be analyzed 

tot_mdnbr(l;TOTAL_RONS) = 0; %initialize the data array 

cd{’4000 Runs 15 June 2003'); 
load run_dnb_data 
tot_mdnbr(1:4000) = mdnbr; 

cd .. 

%analyze first 4000 runs 

[low_conf_mean,high_conf_std] = mc_dist_analysis(tot_mdnbr(1:4000)); 

y4000 = normal_dist(low_conf_mean,high_conf_std,X); 

mean4000 = low_conf_mean - 1.65*high_conf_std 

%look at the overall effect 

SKIP = 5; 

[n,bin_cent] = hist(tot_mdnbr,25); 

n = n .* (1/(length(tot_mdnbr)♦(bin_cent(2) - bin_cent(1)))); 
bar(bin_cent,n); 
hold on; 

plot(X(l:SKIP:end),y4000(l:SKIP:end),'he'); 

xlabel ( 'MDNBR' ) ; 

ylabel('Probability Density'); 

title('PLOFA - Bowring MDNBR Distributions'); 



m 
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Two important utility functions are used here, tiie first, mc_dist_analysis.m, accepts 
the MDNBR sample values as data, and returns the 95 percent lower confidence mean 
and 95 percent upper confidence standard deviation. 

%mc_dist_analysis .m 

function [lc_mean,hc_std] == mc_dist_analysis (data) 

[m,n] = size(data’); 
dof = m-l; 

%get a handle to the excel workbook functions 
ex = actxserver(’excel•application’); 

Iset (ex,’visible’,’false’) ; 

func = get(ex,’worksheetfunction’); 

samp_mean = mean (data (1 :m)); 
samp_std = std(data (l:m)) ; 

if (dof < 1000) 

chi = invoke (func,’chiinv’ ,* 0. 95’ ,nuiTi 2 str (dof)) ; 
upp__conf_std = samp_std*sgrt (dof/chi); 
else 

upp_conf_std = samp_std; 

end 

low_conf__mean = samp_mean - 

invoke(func,’confidence’,’0.1’,num2str(upp_conf_std),... 
num2str (m)); 

lc_mean = low_conf_mean; 
hc__std = upp_conf_std; 

delete(ex); 


Microsoft Excel workbook functions ‘chiinv’ and ‘confidence’ are used in this 
procedme to eliminate tbe requirement to program these rather complicated functions by 
hand. 

The Matlab diary results for this run are: 
low_con^mean = 


1.4353 
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highcon^std = 


0.0282 


mean4000 = 


1.3888 
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Appendix 5 steady State CPR Calculations 

This appendix presents the scripts that were used to generate the steady-state CPR 
vs. MDNBR and MDNBR vs. Power curves shown in Chapter 3. 

MDNBR vs Power 

This is a very straight-forward algorithm that is implemented with only a few lines of 
Matlab code for each correlation included in the plot. Most of the Matlab code is 
dedicated to producing an attractive gr^hical output. 

The high-level driver script is given here: 


%pow9r__vary_all ,m 

% obtain the mdnbr vs. power data for each correlation 
powe r_r ange_macb; 
pow_it * zeros(20,4); 
pow_it(:,1) = power *; 
mdnbr_it (:, 1) “ mdnbrjp; 

% 

power_range_baw2; 
pow_it{:,2) = power*; 

Eidnbr__it (:, 2) = mdnbrjp; 

% 

powe r_range_w31; 
pow_it(:,3) = power *; 
mdnbr_it (:, 3) = mdnbr_p; 

% 

powe r_r ange_groen; 
pow_it(:,6) = power*; 
mdnbr_it (:, 6) = mdnbrjp; 

% 

power_range_epri ; 
pow_it(:,4) = power*; 
mdnbr_it (:, 4) = mdnbrj); 

% 

power_range_bowr 
pow__it {:, 5) = power ’ ; 
mdnbr__it (:, 5) - mdnbr_j>; 

% plot the data 

X - Ixnspace(min{pow_it(1,:)),max(pow_it(end,;)),1000); 
plot (pow_it (:, 1) ,mdnbr_it (:, 1), *-og*, *LineWidth*,2); 
hold on 

plot (pow_it (:, 2) ,mdnbr_it (:, 2), * “4-k *, *LineWidth*, 2); 
plot (pow_it (:, 3) ,mdnbr_it (:,3), *“sc', *LineWidth*,2); 
plot (pow_it (:,6) ,mdnbr__it (;, 6), *-*r*, *LineWidth*,2); 
plot (pow_it (:, 4) ,mdnbr__it (:, 4), * -dm*, * LineWidth*, 2); 
plot(pow_it(:,5),mdnbr_it(:,5),*-xb *,* LineWidth *,2); 
plot (X, 1.3,*-r*,'LineWidth*,2) 
title(’MDNBR VS Power’) 
xlabel(*Linear Power (kw/ft)*) 
ylabeK'MDNBR*) 

legendCMacBeth*, *B&W-2*, *W-3L*,'AECL-UO Look-up Table*,*EPRI*,*Bowring*,'MDNBR= 1.3') 
grid on 
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The scripts used to obtain the MDNBR vs. power data are straight-forward as well. 
Two examples are given here®: 


power_rangejgroen.in 

%~——=—****■*—inputs ®'®r*®***®—****s®***—’*«*— 

spreadsheet_filename - strcat(pwd, *\’, U7xl7_trans_Xrss_w31.xls*); 
addpath(’c:\inatlab_svl3\work\research\vipre transient tools*); 

[xl,spread_sheet3 « get_spreadsheet(spreadsheet_filename); 
input^sheet » get_worlcsheet(spread_sheet,’input-nom-dummy*); 

var^filename - *w31_input_dat*; 
input_f ilename* ’ w31_input *; 

g€t_excel_input2^w31 {input^sheet, var_filename); %extract input data from excel. 
%script not provided due to length... 

invoke(spread^sheet,’Save *); 

invoke(spread^sheet,’Close’); %close the file that I was working with 
delete(xl);%delete the activex server object 

FIELD* ’operS.pwrinp’; 

% MIN^POWER « 3.0; %kw/ft 
% KAX^POWEB = 4.75; %kw/ft 
% NUM^STEPS = 20; 

power - linspace{MIN_POWER,MAX_POWER,NOM_STEPS); 
indnbrjp * zeros (NUM^STEPS, 1) ; 


for i - 1:NUM_STEPS 

change_input (var^filename, FIELD,power (i)) ; 
generate_input_file (input_filename, var_filename) ; 
vipre_run J on (input_f ilename, var_f ilename); 
load(’channel^data’); 

%here’s where I need to snag the data 
load(var_filename) % get the input data in my context 
Ihot_chnl_type, j} * find(geom6 **» corr_hot_channel) / 
flow^area”* geomS(hot_chnl_type).careaT 
heatedjperim ■ geom5 <hot_chnl_type) .cph; 

qual ■ channel_equilibriuin_quality(l, :,corr_hot_channel); 
massif lux - channeljnass_flux {corr_hot_channel); %mlbm/hr - ft^2 
systemjpress « operS.pref; %psia 

* 4*flow_atea/heatedjperiia; %this is in inches - must be converted to meters. 
local_press « channel_delta^_local(l, :,corr_hot_channel) + systemjpress; %psia 
loCjheatjflux * channeljSurfacijhf (1,: fCorr^hotjChannel); %btu/ft''2“hr 

%now - convert 

Djhyd - Djhyd * (1/39.37); %in 
localjpress * localjpress .♦ (6.8947); %kPa 
masSjflxix « mass^flux * (1356.222); %kg/m'"2--sec 
loCjheatjflux * loc^heat^flux .* (0.31546e7); % W/m''2 
axialjZones - min(length(qual),length(localjpress)); 
chf_groenjlocal • zeros(axialj 2 ones,l); 
cinbr^groenjlccal ■ zeros (axial^zones, 1) ; 
for k - 1:axialjZones 

chf^groenjlccal (k) • groev^lu (D^hyd, localjpress (k) ,masSjflux, qual (k) ) ; 

%modify by the appropriate factor 
%kl 

kl • 1; 

if (D hyd > 0.002) & (D^hyd < 0.016) 


® It would be useful to see the script used to obtain MDNBR vs Power data for the AECL-UO ccnrelation as 
well as a coirelation diat is built-in to VIPRE - if only to highlight the added logic required for the AECL- 
UO correlation.. 
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kl = (0.008/D_hyd)''{l/3) ; 
elseif (D__hyd > 0,016) 
kl = 0.79; 

else 

kl = 1.0; 

end 

%other factors assumed equal to 1 for now... 
chf_groen_local(k) = chf_groen_local(k)*kl; 


if<loc_heat_flux(k) > 0) 

dnbr_groen_local (k) = chf_groen_local (k) /loc_h€at_flux (k); 

else 

dnbr_groen_local(k) « 10.0; 

end 

end 


indnbr_p (i) = min (dnbr_groen_local) ; 

end 


power_range_epri.m 

spreadsheet_filename = strcat(pwd,*\*17xl7_trans_clofa_epri.xls’); 
addpath('c:\matlab_svl3\work\research\vipre transient tools’); 

[xl,spread_sheet] = get_spreadsheet(spreadsheet_filename); 
input_sheet = get_worksheet(spread_sheet,’input-nom-dummy*); 

var_filename = * epri_input_dat ’; 
input_f ilename= ’ epri^input ’; 

get__excel_input2_epri(input_sheet,var_filename); %extract input data from excel. 
%script not provided due to length_ 

invoke(spread_sheet,’Save’); 

invoke(spread_sheet,’Close*); %close the file that I was working with 
delete(xl);%delete the activex server object 

FIELD= * operS.pwrinp *; 

TEMP_FIEIiD = ’operS.hin’; 

MIN_POWER = 3.0; %kw/ft 
MAX^POWER = 5.5; %kw/ft 
NUM_STEPS = 20; 

NCM_POWER = 3.04; %kw/ft 
NOM_INLET_TEMP * 557.6; % degrees F 
NOM_DELTA_T = 67.0; %degrees F 

power = linspace{MIN_POWER,MAX_POWER,NUM_STEPS) ; 

new_Tin = NOM_INLET_TEMP .* (ones(NUM_STEPS,1)) - (0.5).* ((power’ - 
NC»d_POWER) ./NOM_POWER) . *NOM_DELTA_T; 
mdnbr_p = zeros(NUM_STEPS,1); 

for i = 1:NUM_STEPS 

change_input (var^filename, FIELD,power (i)) ; 
change_input (var_filename, TEMP^FIELD,new_Tin(i)); 
generate_input_file (input^filename, var_filenaine); 
vipr€_run_j on (input_f ilename, var_filename) ; 
load(’channel_data’); 
mdnbr_p(i) * corr^mdnbr; 

end 
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CPR vs MDNBR 


The creation of Ais curve was somewhat more complicated. The goal was to 
produce a plot where each correlation tmder consideration would be varied over a 
uniform range of power ratios. To accomplish this, one must know what linear power 
(for the given power shape) produces the condition of MDNBR = 1. This was computed 
with the first script presented. The second script cpr_vaiy_all.m uses: 

power_ratio_epri.m 

%pcwer_ratio_epri 


spreadsheet_filename *• strcat(pwd, *\*, U7xl7_trans_clofa_epri.xls*); 
addpath(*c:\itiatlab_svl3\work\research\vipre transient tools*); 

lxl,spread_sheet] * get_spreadsheet (spreadsheet_filenaine) ; 
input_sheet « g€t_worksheet(spread_sheet,'input-nom-duimiiy*); 

var^filename * *epri_input_dat*/ 
input^f ilename* * epri^input *; 

get_excel_input2_epri(input_sheet,var^filename); %extract input data from excel. 

%script not provided due to^length.. 

invoke(spread_sheet,* Save *); 

invoke(spread_sheet,'Close*); %close the file that I was working with 
delete(xl);%delete the activex server object 

% ssiS-suKs =£=1 SIS s; =.3:;3SASBS=Eaisss s s saiass =ss=£3Bs sssss sassss: jssss s s 

Here a simple Bisection algorithm is used to find the power that produces MDNBR = 
1 (witii a tolerance on MDNBR specified at 0.0001). 


FIELD* * Ope r5.pwrinp *; 

NOMINAL POWER * 3.04; 

MIN RANGE « 4.0; 

MAX^RANGE « 5.2; 

MAX^ITER * 100; 

TARGET « 1.0; 

TOL * le-4; 
iter • 0; 
cont - 1; 
pow « MIN_RANGE; 

while{cont**l) 

iter « iter + 1 

change_input (var^filename, FIELD, pow); 
generate_input_file (input^filename,var_filename>; 
vipre_run_j on (input^f ilename, var_f ilename); 
load{* channel_data *7; 
mdnbrjp * corr_itidnbr; 

if {mdnbr__p < (TARGET - TOL)) % reduce power 
MAX__RANGE - pow; 
pow « 0.5*(pow + MIN^RANGE); 
elseif (mdnbr_p > (TARGETtTOL)) %increase power 
HINDRANCE * pow; 
pow « 0.5*(pow+MAX_RANGE); 

else 

%desired power 
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sprintf('Predicted Power for CHF = %d*,pow) 
sprintf ('Predicted CPR = %d* ,pow/NOMINAL_POWER) 
cont ” 0; 

end 

if (iter > MAX_ITER) 

'iteration failed!!!' 
cont =0; 

end 


end 


A version of this script is written for each correlation. The ou^ut is a very close 
approximation of the power where MDNBR=1 for each correlation. 

Armed with this data, a series of VIPRE runs had to be made to find the MDNBR 
that corresponds to a set of specified CPR points (for the plot provided, CPR is to vary - 
for each correlation - between 2.0 and 0.98). This gives the MDNBR for each specified 
CPR for each correlation, and hence the desired plot can be made. 

cpr_vary_all.m 


%ordered list of linear heat-rates that result in MDNBR = 1. 
%[MacBeth,B&W-2,W-3L,SPRI,Bowring,AECL-UO] 
pow_one = [5.853,4.32,4.571,4.7547,4.871,4.342]; 


MAX_CPR = 2.0; 

MIN_CPR = 0.98; 

NUM_STEPS =20; 

pow_max = pow_one .* (1/MIN_CPR); 
pow_inin = pow_one .* (1/MAX_CPR); 

pow_it = zeros(NDM_STEPS, 6); 
mdnbr_it = zeros(NUM_STEPS,6); 


These are slightly modified versions of the same functions presented previously - the 
scripts used in power_vary_all.m are just re-formatted slightly to behave as functions. 
Logically there is no difference. 


[pow_it (:, 1), mdnbr_it (:,!)]= power_range_iciacb (pow_min {1), powjnax {1), NUM__STEPS); 
[pow_it (:, 2), mdnbr_it (:, 2) ] =power_range_baw2 (pow_inin {2), pow__max (2), NUM_STEPS) ; 
[pow_it (:, 3) ,mdnbr_it (:, 3) ] =power_range_w31 (pow__min (3),pow_max (3),N0M_STEPS); 
[pow_it (:, 6), mdnbr_it (:, 6) ] =power__range_groen (powjrtiin (6), pow_max (6), NUM_STEPS); 
[pow_it (;, 4),mdnbr_it (:, 4) ] =power_range_epri (pow_min (4),pow_max (4),NUM_STEPS); 
[pow_it {:, 5) ,mdnbr_it (:, 5) ] =power_range_bowr (pow_min (5) ,pow_iaax (5) ,NUM_STEPS); 

for i-l:6 

cpr_it(:,i) = (pow_it(:,i) .* (l/pow_one(i))) (-1); 

end t 
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Here, I would save the data, so that if the plot needed to be re-fonnatted in any way, 
the data would still be available.** 


save cpr_data_file pow_it mdnbr_it cpr_it 
figure 

plot (cpr_it (:, 2),melnbr_it (:, 2),'-+k’,'LineWidth ' , 2 ); 
hold on. 

plot(cpr_it(:,1),mdnbr_it(;,1),'-og','LineWidth', 2); 
plot (cpr_it (:, 3) ,iiidnbr_it (:, 3), • -sc•,'LineWidth', 2); 
plot(cpr_lt(:,6),ffldnbr_it(:,6),'-*r', 'LineWidth', 2); 
plot(cpr_it{:,5),mdnbr_it(:,5),’-xb’,'LineWidth',2); 
plot(cpr_it(:,4),mdnbr”it(:,4), '-dm', 'LineWidth' ,2) ; 

set{get(gcf,'CurrentAxes'),'XDir','reverse') Smakes the XDir increasing right to left 
titleCMDHBK vs Critical Power Ratio','FontSire',12,'FontWeight','bold') 
xlabelCCPR', 'FontSize',12) 
ylabel('MDNBR') 

legend{'BSW-2','MacBeth','W-3L','AECL-UO Look-up Table','Bowring','EPRI') 
grid on 


^ Hie computational time required to generate the data required for the plot was not large, but not 
insignificant either. 120 VIPRE runs were used to create all of the interior points. Hiis takes a couple of 
minutes, and it is worfli-while to save the data while you are fine-tuning die plot. 
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Appendix 6 Uncertainty Analysis Sample 

Calculations 


Improved Thermal Design Procedure 

The Improved Thermal Design Procedure (ITDP) was described fully in Chapter 3. 
In this appendix, a complete sample calculation will be made to determine the 
DNBRjjj)p for the W-3L correlation. The imcertain parameters, and the the associated W- 
3L correlation sensitivities are provided in Table 18 for reference. For illustration, all 
uncertain parameters will be assumed to have a rectangular distribution. 


Parameter 

Mean Value 

Range 

W-3L Sensitivity 

Core Inlet 
Temperature 

557.6 

±4®F 

3.65 

Coolant Mass Flux 

1.235*^*'” 

Hr 

±5% 

0.778 

Core Linear Power 

3.04^ 

ft 

±2% 

1.601 

System Pressure 

2259.4 psia 

± 30 psia 

0.111 


1.02 

±.02 

0.595 


Table 18: Parameter Distributions and W-3L Sensitivities. 
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The primary intermediate resiilt will be to compute cr^ . As shown in Chapter 3, this 
value can be expressed as follows: 


2 2 2 












2„2 


\ 


+-+//X 




For this application diere are five parameters, therefore n = 5, The mean values are 
listed above, using the assumption that the parameters are rectangularly distributed across 
the ranges listed, can computed firom 


12 


Core Inlet Temperature: (7.^ = = 5.33 

12 


Mass Flux: 


Core Linear Power: 


System Pressure: 




^2 [1.253(1.05 - 0.95)f 


0-3 = 


12 

[3.04(1.02-0.98)r 
12 


0.001308 


= 0.001232 


2 (2289.4 - 2229.4)^ 


<74 = 


12 


= 300 


<Tc = 


(1.04-1.0)^ 


12 


= 0.0001333 


Using die above computed values with the given values for 
and that is by construction unity, the expression for cr^ becomes: 


= (3-65)' + (0-778^ ff + • 


(557.6)' 


(1.253)' 


(l.60iy 


0.001232 /_^2 300 


■+(0.777)' 


• + (0.595y 


0.0001333 


(3.04)' ■ ' ' (2259.4)' ' " ' (l.02)' 

10“^ • (2.284 + 5.044 + 3.417 + 0.354 + 0.454) = 11.554 x 10' 


198 0/257 









The last line is presented explicitly to allow one, at a glance, to determine which 
parameters weigh most heavily on the total uncertainty of DNBR. 

Now we must find the factor 

F„= My .645.= 1 -1.645• = 1 -1.645^11.554x10-" = 1 -0.05591 = 0.9441 


And DNBRjjjyp can now be found as: 


DNBRppop = ^ _i:3_ 


0.9441 


Monte Carlo Uncertainty Procedure 


The Monte Carlo Uncertainty Procedure (MCUP) was discussed in detail in Chapter 
3. The appendix provides a detailed sample calculation for the LR/SS casualty using die 
W-3L correlation. For this analysis, 2000 transient runs were completed and, for each 
run, the MDNBR was recorded. The analysis was completed using a set of Matlab 
scripts as shown in a previous appendix. For the sake of illustration, I will perform the 
analysis using only the first 10 transient runs so that the calculations can be shown 
e3q)licitly. 

The resulting MDNBR for the first 10 runs are: 

2.1600 

2.1430 

2.0910 

2.1570 

2.1960 

2.1050 

2.1900 

2.1530 

2.2130 

2.1420 


The sample mean is given by: 
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=2.155 

Nti 

The sample standard deviation is given by: 


^MDNBR ~ _ 2^ j =0.0383 


Next, the sample standard deviation is shifted up to the 95% one-sided upper 
probability value. This is done using the Distribution with n-l=l 0-1=9 degrees of 
freedom. The result is =3.3251." The sample standard deviation is adjusted as 


follows; 


^ifDNBR ~ ^MDNBR 


n -1 ^ r 9 T 

-7- =0.0383 —^ =0.0630 

X L3.3251J 


Note that since friere were so few samples taken, the required confidence limit 
imposes a dramatic adjustment on the sample standard deviation. For larger samples of 
size, for example, 1000, the sample standard deviation is virtually unchanged.^ 

Now, using the 95% confidence standard deviation, the sample mean is adjusted to 
the 95% one-sided lower probability value. This is done using the Student’s t 
Distribution as follows: 

// - « ^^MDNBR 

^MDNBR nMOmK /“ 


The t value can be obtained from a standard table. The result is: 

1‘mm, =2.1550-(1.645)^^ = 2.1222 

The is then compared to the correlation limit MDNBR for the W-3L 

correlation (1.3) to verify that thermal limits are not exceeded. 


* Actually, the value given is die result of the MS Excel workbook function CHIINV which numerically 
inverts the x^ distribution. The result read off from a table given in reference [24] gives the 
value =3.33. 

" As discussed earlier, for n > 1000, this adjustment is not even made. 
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Appendix? FRAPCON IntorfdCG 

Code for the Matlab-FRAPCON Interface is presented in this appendix. All of the 
data for the input variables exposed by this interface is entered directly into a Matlab- 
style script An example is provided here: 


FRAPCON Input Data Collection 

The input data itself is provide here: 

%f rap__data .m 

%FRPCK section start 
im=71; %ii\nnber of time steps 

na=12; % numer of equal-length axial regions along the rods 
inechan=2; %not sure what this means 

ngasr=15; ^number of equal volume rings in pellet for gas release calculations 
%FRPCN section end 

%F?sPCON section start 

cpl-24.00; %cold plenum, length in inches 

crdt=0.0; %iRitial thickness of crud layer on cladding outside surface in mils 
thkcld=0.034; %cladding wall thickness in inches 

thkgap=0.0045; %pellet-cladding as-fabricated gap thickness in inches 
dco=0.5512; %cladding outer diameter — in inches 

pitch*=0.5712; %center-to-center distance between rods in a square array (inches) 
den=96.0;%as-fabricated apparent fuel density 
dspg*=0.3;%outer diameter of plenum spring (inches) 

fa=1.55; %peak-to-average power ratio for cosine type axial power distribtution 
dspgw=0.04; %Diameter of plenum spring wire (inches) 
enrch~9.98; %fuel pellet u-235 enrichment 
fgpav=14.7; %initial fill-gas pressure 

hdish=0.0; % height of pellet dish^ assumed to be a spherical indentation (inches) 

hplt=0.5; % height of each pellet (inches) 

icm=4; %cladding type indicator 2- zirc 2, 4 - zirc 4 

gadoln=2.5; %weight fraction of gadolinia in urania-gadolinia fuel pellets 

icor=2; %index for curd model 0,1-constant crud , 2=variable crud— growth rate is CRDTR 

idxgas«l; %initial fill-gas type indicator l=He, 2=air, 3=nitrogen, 4-fissicn gas, 

5=argon 

iplant=-2; %signal for which type of reactor: -2-pwr, -3=bwr, -4=hbwr 

ig=l; %Indicator for axial power shape — 1 = chopped cosine, 0 = user defined 

%ivoid=l; 

jdlpr=0; %output print control: 0=all axial odes, l=peak-power axial node 
totls=14.0; %the total (active) fuel column length 

roughc=1.97e-5; %the cladding surface arithmetic mean roughnes, peak to average (inches) 
roughf=8.3e-5; %the fuel pellet surface arithmetic mean roughness, peak to average 
(inches) 

vs^lOO.O; %number of turns in the plenxim spring 

nunits=l; %signal for unit system to be used for input and output l=british, 0=si 
(warning for british units) 

rsntr=150.0; %the increase in pellet density expected during in-reactor operation (kg/m3) 
nsp=0; %signal for time-dependent input arrays (P2,TW,G0) 0-single values, l=each time 
step 

p2=2250.0; %pressure (psia) 

tw*557.6; %coolant inlet temperature. (F) 

go=1.27e6; %mass-flux of coolant around fuel rod. (Ib/hr-ft2) 
qiipy=2.0; %linear heat rate during each time step — in kw/ft 
time=41; %n\ 2 mber of days per time step 
slim = 0.05; %limit on swelling — volume percent 
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%FRPCON section end 

This data is called into the Madab workspace context, and the data structures 
required for input file generation are provided with the following script The only 
required input is a character string representing the desired name of the input variable 
file: 


function frap_input_data {var_file_naxne) 
frap_data; 

frap_title=»This is the title*; 
out_que « char(*frap_title*); 
out^que « char (out_que, *iin* >; 
out_gue » char(out“que,‘na*); 
out^que * char (out_que, *mechan*) ; 
out_que « char (out^que, *ngasr*); 
out_que « char (out_que, * cpl *) ; 
out^que * char (out_que, *crdt *) ; 
out_que « char(out_que,’thkcld*); 
out_que * char (out_que,'thlcgap*); 
out_que « char (out_que, *dco ’); 
out_que « char(out^que,'pitch*); 
out_que * char{out_que,* den *); 
out_que = char(out_que,*dspg*); 
out_que ■= char (out_que, * fa *) ; 
out_que ■ char (out_qu€, *dspgw*); 
out_que * char (out_que, *enrch’); 
out_que « char (out_que, * fgpav*); 
out_que « char (out_que, *hdish') ; 
out_que « char (out^que,’hplt’); 
out_que « char(out_gue,*icm*); 
out_que * char (out_que, * gadoln *) / 
out_que « char(out_que,'icor*); 
out_que ■ char (out_que , * idxgas *); 
out_que » char (out_que, * iplant *); 
out^que * char (out_que/ * iq’); 
out_que - char (out_que , * j dlpr *); 
out_que * char {out_que, *totl*) ; 
out_que * char(out_que,* roughc *); 
out_que - char (out_que, *roughf *); 
out^que - char(out_que, *vs*); 
out_que * char(out_que,*nunits *); 
out_que « char (out__que, • rsntr *); 
out_que * char (out_que, *nsp*) ; 
out_que ■ char(out_que,*p2 *); 
out_que “ char {out_que, *tw*) ; 
out_que » char (out_que, * go *); 
out_que « char (out^que,'qmpy*) ; 
out^que * char (out^que, * time *); 
out^que “ char(out”que,•slim*); 


out^que » cellstr (out_que); 


%save the input variables to file to allow further manipulation 
%var_file_name * * input__vars *; 

%check to see if the file currently exists — if it does, delete it: 
if exist(strcat(var_file_naine, * .mat •)) 2 

delete (strcat (var_fiTe_naiae, * .mat»)); 

end 

%now save all of the appropriate variables 
save (var_file_name,char (out_que (1))); 
for i « 2:length(out_que) 






save (var_file__naine^char (out^que (i)),'-append’) ; 

end 

%save the ont^que itself so it can be used for re-saving a modified version of the 
variables later 

save (var_f ile^name, * out__que ’, ’ -append ’); 


Now that this data is collected and stored to hard-disk, the input file itself can be 
generated. 


Input File Generation 

The code is provided here: 


%gen_f rap_input, m 

function gen_frap_input (data, input_file_name); 


load(data); 

fid - fopen(input_file_naine, ); 

gen_frap_top(fid); %creates the un-changing beginning to the input deck 
for i=l:length(out_que) 

switch char(out_que(i)) 
case ’im’ 

gen_im(fid,im); %this must be the first in section SFRPCN 
case *na* 

gen_na(fid,na); 
case *mechan’ 

gen_mechan (fid, mechan); 
case *ngasr' 

gen_ngasr(fid,ngasr); %this must be the last in section $FRPCN 
case * cpl’ 

gen_cpl(fid,cpl); %this must be the first in section $FRPCOH 
case * crdt' 

gen_crdt(fid,crdt); 
case *thkcld' 

gen_thkcld(fid,thkcld); 
case * thkgap * 

gen_thkgap(fid,thkgap); 
case *dco* 

gen_dco(fid,dco); 
case ’pitch’ 

genjpitch{fid,pitch); 
case *den* 

gen^den(fid,den); 
case ’dspg* 

gen_dspg(fid,dspg); 
case *fa’ 

gen_fa(fid,fa); 
case *dspgw' 

gen_dspgw (fid, dspgw) ; 
case ’enrch’ 

gen_enrch(fid,enrch); 
case ’fgpav’ 

gen_fgpav(fid,fgpav); 
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case *hdish* 

gen_hdish(fid,hdish); 
case ’hplt* 

gen_hplt{fid,hplt); 
case ’icm’ 

gen_icm{fid,icm); 
case 'gadoln* 

gen_gadoln(fid,gadoln); 
case 'icor’ 

gen_icor(fid,icor); 
case *idxgas' 

gen_idxgas(fid,idxgas); 
case »iplant’ 

gen_iplant(fid,iplant); 
case *iq* 

gen_iq{fid,iq); 
case *jdlpr’ 

gen_jdlpr(fid, jdlpr) ; 
case *totl* 

gen_totl(fid,totl); 
case *roughc* 

gen_roughc(fid,roughc); 
case *roughf* 

gen_roughf(fid,roughf); 
case *vs’ 

gen_vs (fid, vs); 
case ’nunits’ 

gen_nunits(fid,nunits); 
case *rsntr* 

gen_rsntr{fid,rsntr); 
case *nsp* 

gen^nsp (fid, nsp); 
case *p2* 

gen_p2 (fid,p2); 
case *tw’ 

gen_tw (fid, tw) ; 
case *go* 

gen_go(fid, go); 
case 'qn^jy* 

gen_qn^y (f id, qn^y, iin) ; 
case ’time’ 

gen_time (fid, time,im); 
case ’slim’ 

gen_slim(fid,slim); %this one must always be last to get the $end 


end 


end 

St *fclose(fid); 


The above function works in a way that is analogous to the input-file generation 
script for tiie Matlab-VIPRE Interface - only the function names are different The code 
for actually writing flie input file is provided here: 


%gen_frap_top.m 
function gen_frap_top(fid) 

Str « ’FILE05«”nullfile”, STATUS* ”UNKNOWN” , FORM* ” FORMATTED”,’/ 

Str2 * ’ CARRIAGE CONTROL *”NONE*”; 

Str3 * ’FILE06-”outIrisO”, STATUS* ” UNKNOWN ” , CARRIAGE CONTROL * ’’LIST’”; 
str4 “ I. 

fprintf(fid,’\n%s \n’,str); 
fprintf(fid,'%s\n’,str2); 
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fprintf(fid,*%s\n*,str3); 
fprintf(fid,* %s\n *,str4); 


%gen_im.rR 

function gen_iia (fid, im) 

str = sprintf{*im = %4.0f*,im); 
strl=sprintf(*$frpcn*); 
fprintf{fid,*\n%s *,strl); 
fprintf(fid,’\n%s,\n *,str); 


%gen_na(fid,na) 

function gen_na{fid,na) 

str = sprintf {’na=%4.0f Sna); 
fprintf(fid,*%s,\n*,str); 


%gen__mechan (fid, mechan) 

function gen_mechan(fid,mechan) 

str = sprintf(*mechan*%4.Of,mechan) 
fprintf(fid,* %s,\n *,str); 


%gen_ngasr(fid,ngasr) 

function gen_ngasr(fid,ngasr) 

str = sprintf(*ngasr=%4.Ofngasr); 

fprintf(fid,’%s,\n*,str); 
fprintf(fid, * $€nd\n'); 

%gen_thkcld(fid,thkcld) 

function gen^thkcld(fid,thkcld) 

str = sprintf(*thkcld=%7.5f*,thkcld) 

fprintf(fid,'%s,\n*,str); 

%gen_cpl(fid,cpl) 

function gen_cpl(fid,cpl) 

str = sprintf(’cpl-%5.2f’,cpl); 
fprintf(fid,’$frpcon\n*); 
fprintf(fid,’%s,\n *,str); 

%gen_crdt(fid,crdt) 

function gen_crdt(fid,crdt) 

str = sprintf(*crdt=%5.2f^,crdt); 

fprintf(fid,* %s,\n *,str); 

%gen__thkgap (fid, thkgap) 

function gen_thkgap(fid,thkgap) 








str “ sprintf(’thkgap«%7.5f*,thlcgap) 
fprintf(fid,*%s,\n’,str); 

% gen_dc o(fid,dco) 
function gen_dco(fid,dco) 
str * sprintf(*dco«%7.5f’,dco); 
fprintf(fid,*%s,\n*,str); 

%genjp>i tch (f id, pi tch) 

function genjpitch(fid,pitch) 

str * sprintf(*pitch*%7.5f*,pitch); 

fprintf(fid,'%s,\n*,str); 

%gen_den(fid,den) 

function gen_den(fid,den) 

str * sprintf(’den=%5.2f*,den); 

fprintf(fid,*%s,\n*,str); 

%gen_dspg(fid,dspg) 
function gen_dspg(fid,dspg) 
str « sprintf(*dspg*%7.5f’,dspg); 
fprintf(fid,*%s,\n’,str); 

%gen_fa(fid,fa) 
function gen_fa(fid,fa) 
str - sprintf(*fa-%7.5f’,fa); 
fprintf(fid,’%s,\n*,str); 

%gen__dspgw (fid, dspgw) 
function gen^dspgw(fid,dspgw) 
str ■= sprintf ('dspgw*%7.5f *,dspgw) ; 
fprintf(fid,*%s,\n*,str) ; 

%gen_enrch(fid,enrch) 
function gen_enrch(fid,enrch) 
str « sprintf{*enrch*%7.5f’,enrch); 
fprintf(fid,*%s,\n’,str); 
%gen_fgpav(fid,fgpav) 
function gen_fgpav(fid,fgpav) 
str * sprintf(*fgpav-%7.5f*,fgpav); 
fprintf(fid,*%s,\n’,str); 

%gen_hdish(fid,hdish) 



function gen_hdish (fid, hdish) 
str = sprintf{*hdish=%7.5f’,hdish); 
fprintf(fid,’%s,\n’,str); 

%gen__hplt (fid,hplt) 
function gen_hplt(fid,hplt) 
str = sprintf ('hplt='%7.5f * ,hplt) ; 
fprintf(fid,*%s,\n*,str); 

%gen_icm(fid,icm) 
function gen_icm(fid,icm) 
str = sprintf(’icm=%7.Of*,icm); 
fprintf(fid,*%s,\n’,str); 

%gen__gadoln (fid, gadoln) 
function gen_gadoln( fid, gadoln) 
str = sprintf(*gadoln=%7.5f’,gadoln) 
fprintf(fid,* %s,\n*, str) ; 

%ger-_icor {fid,icor) 
function gen_icor(fid,icor) 
str = sprintf (^icors=%7.0f Sicor); 
fprintf (fid, ^%s,\n\str); 

%gsn_icixgas (fid, idi-igas) 
function gen_idxgas{fid,idxgas) 
str * sprintf('idxgas=%7.Of*,idxgas) 
fprintf(fid,’%s,\n',str); 

%gen_iplant(fid,iplant) 
function gen_iplant(fid,iplant) 
str = sprintf(*iplant=%7.0f*,iplant) 
fprintf(fid,*%s,\n*,str); 
%gen_iq(fid,iq) 
function gen_iq(fid, iq) 
str = sprintf(*iq=%7.Of * ,iq); 
fprintf(fid,* %s,\n*, str) ; 

%gen_jdlpr(fid,jdlpr) 
function gen Jdlpr (fid, jdlpr) 
str = sprintf(*jdlpr=%7.Of’,jdlpr); 
fprintf(fid,*%s,\n',str); 

%gen_totl(fid,totl) 






function gen_totl (fid.totl) 
str - sprintf(’totl=%7.3f^totl); 

fprintf (fid, •%s,\n‘,str); 

%gen_roughc(fid,roughc) 
function gen^roughc(fid,roughc) 
str - sprintf(»roughc*%10.9f*,roughc) 
fprintf(fid,»%s,\n*,8tr); 

%gen_roughf(fid,roughf) 
function gen_roughf(fid,roughf) 
str = sprintf(*roughf*%10.9f’,roughf) 
fprintf(fid,•% s,\n *,str); 

(fid,vs) 

function gen_vs (fid, vs) 
str - sprintf(*vs«%7.2f»,vs); 
fprintf(fid,’%s,\n•, str); 

%gen_n\jLnits (fid, nunits) 
function gen_nunits(fid,nunits) 
str « sprintf(*nunits*%5.Of’,nunits); 
fprintf(fid,* %s,\n *, str); 

%gen_rsntr(fid,rsntr) 
function gen_rsntr(fid,rsntr) 
str * sprintf(*rsntr«%9.3f*,rsntr); 
fprintf{fid,’%s,\n’,str); 

%g9n_nsp (fid, nsp) 
function gen_nsp(fid,nsp) 
str - sprintf(’nsp«%9.0f’,nsp); 
fprintf(fid,’%s,\n’,str); 

%gen_p2(fid,p2) 
function genjp2(fid,p2) 
str - sprintf(’p2=%9.3f’,p2); 
fprintf(fid,’%s,\n’,str); 

%gen_tw(fid,tw) 
function gen_tw{fid, tw) 
str « sprintf(’tw^%9.3f’,tw); 
fprintf(fid,’% s,\n’,str); 
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function gen__go(fid,go) 

str = sprintf(*go=%10.2f’,go); 

fprintf(fid,’%S/\n*,str); 

%gen_qinpy (fid, qrnpy) 
function gen^qmpy(fid, qrnpy, im) 

str * streat (*qmpy=* ,nuiR2str{im) ,*** ,num2str(qrnpy)) ; 

fprintf(fid,’%s,\n*,str); 

%ger!_tim€ (fid, time, im) 

function gen_time (fid, time, im) 

fprintf(fid,’time= ’); 
for i = l:im 

if(mod(i,7)==0) 

fprintf(fid,*\n*); 

end 

fprintf(fid,’%5.Of,»,i*time); 

end 

fprintf (fid, * \n *); 

%gen__slim (fid, slim) 

function gen^slim (fid, slim) 

str = sprintf(’slim“%5.4f*,slim); 

fprintf(fid,'%s,\n’,str); 
fprintf (fid, * \n $endM ; % ending 

FRAPCON Execution Coordination 

The FRAPCON execution coordination scripts have a function similar to those for 
the Matlab-VIPRE interface described in Appendix 2. In general tiiis script is responsible 
for copying the axrtomatically generated input file to the directory where the FRAPCON 
executable resides, and copy the output files back to the Matlab working directory where 
the results can be parsed and analyzed. 

The code is presented here: 


function frap__r;in(inputfile) 

%takes a frapeon inputfile as input, and returns a stusum.txt that is a product of the 

%frapcon run. %inputfile is a string 

outdirectory = pwd;%strcat(inputfile,’-out*); 

delete(’fuel_data.mat'); 

current_dir = pwd; 

copyfile(inputfile,’c:\matlab_svl3\bin\frapcon\frapcon.txt’); 

%transfer control to the vipre directory 
cd(’c:\matlab_svl3\bin\frapeon'); 

%ensure that I have access to the callVipre.dll 
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addpath(* c:\matlab_svl3\bin\frapcon’); 

%execute the system call 
callfrapcon; 

%now delete the stupid files 

delete(* frapcon.txt *); 
delete(*nullfile’); 

%copy the useful files 

copyfile{’outlrisO ’, strcat(outdirectory,*\outlris0’)); 

copyfile(* stusum.txt ’, strcat(outdirectory,* Xstusum.txt M); 

copyfile('stustrain.txt *,strcat(outdirectory,»\stustrain.txt *)); 

copyfile (' stustiin2. txt *, strcat (outdirectory, * \8tusuin2. txt ’)); 

copyfile(’stusum3.txt *,strcat(outdirectory,*\stusum3.txt *)); 

delete(’stusum.txt *); 

delete(* stustrain,txt *); 

delete(* stusum2.txt *); 

delete(* stusum3.txt’); 

delete(*outlrisO*); 

%cd(current_dir); 

%copyfil€ (’parse^stusum.m', strcat {outdirectory,' \parse_stusuin.m*)) ; 
%cd current_dir; 
cd(outdirectory); 
parse_stusum; 

%cd ; 


Output Data Parsing 

As with flie Matlab-VIPRE interface, once the ou^ut files are placed in the Matlab 
working directory, the data must be parsed to be in a format that can be used by the 
analyst This task is carried out by die next script: 


%parse_stusuin.m 
function parse^stusum 

COLUMNS * 22; %nuinber of data columns — this shouldn’t change 
NDM_POWER STEPS *71; %this could be different for every file 
NUMJOCIAL^NODES « 12; 

load stusum.txt; %bring the data into the space 
load stustrain.txt; 
load stusum2.txt; 

%initialize data structures 
day * stusum(:,2); 
peak_node * stusum(:,3); 
bumup - stusum(:,4); %MWd\lcgU 
power « stusum{:,5); %Kw\ft 
clad_od_ten^ « stusum{:,6); 
clad_ave_ten^ » stusum(:,7); 
clad_id_ten^ * stusum (:, 8) ; 
gap « stusx2m(:,9); %mils 
fuel_od_temp * stusum (:, 10); 
fuel_ave_temp ■ stusum (:, 11) ; 
fuel_cl_ten^ * stusum (:, 12) ; 
centjpsi “ stusum(:,13); 
clad_hoop_stress ■ stusum(;,14); 
clad_axial_stress « stusum(:,15); 

Gladystrainjpet * stusum(:,16); 
fuel_od * stusum(:,17); 
gap_cond « stusum(:,18); 
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gap_pressure * stusiain{: r 19) ; 
fission_gas_rel = stusviin(:, 20); 

2 irc_oxidejndls = stusmn(; ,21); 
h_2jppm « stusiini{ :,22); 

%stustrain section. There are 8 pairs of data items for 


fueller »= zeros (N0M_P0WER_STEPS,1) ; 

f uel_sw=f uel_cr ; 

fuel_exp=fuel_cr; 

fuel_rel=fuel_cr; 

clad_j>e nn=*f ue l_cr ; 

clad_recov=fuel_cr; 

clad_tot=fuel_cr; 

index=0; 

for i=l:6:N0M_POWER_STEPS 
index » index+1; 
fuel_cr(index)=stustrain(i,1); 
fuel_sw(index)=stustrain{i+l,1); 
fuel_exp(index)=stustrain(i+2,1); 
fuel^rel(index)=stustrain(i+3,l); 
clad3>®^ (index) =stustrain (i+4,1); 
clad_recov(index)-stustrain(i+5,1); 
clad_tot(index)=stustrain(i+6,1); 

end 

ox_layer_thick_iaic * zeros (NUM_AXIAL_NODES,NUM_POWER_STEPS) ; 
index * 0; 

for j = l:NtJM_POWER_STEPS 
for i=l:NDM_AXIAL_NODES 
index=index+l; 

ox_layer_thickjcnic (i/ j) -stusum2 (index, 6) ; 

end 

end 


clear index; 
clear stusvim; 
clear stustrain; 
clear stusum2; 
clear stusum3; 
save fuel data; 


Utility Functions 

Initiation of FRAPCON Execution 

In exactly tiie same manner as VIPRE was instantiated in the Matlab-VIPRE 
Interface, the FRAPCON executable is called for the Matlab-FRAPCON Interface. The 
code for the required dynamically-linked library is provided here. More complete 
explanation of the structure of this file is provided in Appendix 2. 


#include "mex.h" 
#mclude <stdlib.h> 
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#include <stdio.h> 


void mexFunction(int nlhs, mxArray *plhsD, 
int nrhs, const mxArray *prhs[]) 

{ 


piintf("\nCallmg Frapcon...\n "); 
systernffrapstul"); 
return; 


} 


Change of FRAPCON Input 

As with the Matlab-VIPRE Interface, the capability to alter a set of input-data is 
required. This capability is provided wifli the following function: 


%chang€_frap_input.m 

function change_frap_input(input^var,field,value) 
load(input^var) 

expr - strcatCfield, •«’,nuin2str(value), 

%assignin (* caller *, field, value) ; 
eval (expr); 

if exist(strcat(input_var,’.mat *)) -“2 
delete(strcat(input_var,•.mat’)); 
end "" 

%now save all of the appropriate variables 
save (input_var, char (out_que (1))) ; 
for i * 2:length(out^que) 

save(input_var,char(out^que(i)),*-append’); 

end 

%save the out_que itself so it can be used for re-saving a modified version of the 
variables later 

save(input_var,*out_que *,*-append’); 
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Matlab-FRAPCON Interface Example Application 


The following is provided as an example of the type of analysis that can be 
performed widi the Matlab-FRAPCON Interface. 

For Very Long Cycle Length (VLCL) cores, it is often desireable to add an amount 
of burnable neutron poison to provide some reactivity control early in core life. One 
possible option is to use Gadolinium Oxide for this purpose, due to this compound’s high 
neutron absorption cross-section. Unfortunately, use of Gadolinium in the fuel, has the 
tendancy to reduce the thermal conductivity of the fuel, and thus directly acts to increase 
the fuel centerline temperature throu^out life (for a given power level). This increase in 
fuel temperature, in turn, results in increased fuel swelling and fission gas release. 

To quantify these effects, FRAPCON was used. A reference fuel model was input, 
and the Gadolinium concentration was arbitrarily varied between 0 and 15 percent, and 
the results are plotted.® 

The code is presented here: 


%gad__vary.in 

MIN__GAD_CONC = 0; 

MAX_GAD_CONC = 15; %percent 
NUM_STEPS = 5; 

gad_space = linspace (MIN_GAD_CONC,MAX_GAD_CONC,NUM_STEPS); 
num_j>ower_steps = 71; %this is known — may change 
INPUT_FILE_NAME = »test_inp*; 
var_file_name = ’test_var^; 

frap__input_data(var_file_name); % initialise the data 
%make sure I have the files available for modification 
gen_f rap_input (var_file_name, INPUT_FILE_NAME); 

max_fuel_teii^ = zeros (numjpower_steps,NUM_STEPS); 
inax_fuel_od *= max__fuel_temp; %initialize the variables 

for k=l:NDM_STEPS 

%change the input to the required gadolinium concentration 
change_frap_input (var_file_naine, ' gadoln *, gad_space (k)); 
gen_frap_input (var_file_name, INPUT_FILE_NAME); 
f rap_run (INPUT_FILE_NAME) ; 
load fuel_data; 

%data to be saved... 

test_fuel_cl_temp (;, k) = fuel_cl_temp; 

test_fuel_od(:rk) = fuel_od; %both of these are given as a function of burnup 

test_clad_strain(:,k) = clad_strain_pct; 

test_fiss_gas_rel(:,k) = fission_gas_rel; 

test_gap(;,k)-gap; 

test_gap_cond(;/k) = gap_cond; 


* Only (he code is provided here. The purpose of this section is to show how to piece together die low-level 
bits of code presented earlier, into a script that ivill perform some useful analysis (diat would have been 
more difScidt vnfhout the script inter&ce). 
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%pIot the data 

plot (burnup, test_fuel_cl_teii^ (:, 1)); 
hold on ^ 

for i-2:NUM_STEPS-l 

plot(burnup,test_fuel_cl_temp(:,i>,*-k *); 

end 

plot (bumnp, test_fuel_cl_ten^{:,NDM^STEPS), * -r ’) / 

title (•Maximum Fuel Centerline Texi^erature vs Burnup') 

ylabelCMax Fuel CL Temp (F)*) 

xlabeK ’Burnup’) 

hold off 

figure 

plot {bumup, test_fuel_od (:, 1)); 
hold on 

for i-2:NUM_STEPS - 1 

plot(burnup,test^fuel^od(:,i),•-k’) 
end * 

plot (burnup, test_fuel_od(:,Nm_STEPS), ’ -r *); 
title(*Maximum Fuel Outside Diameter vs Burnup*) 
ylabel(*Max Fuel OD (inches)*) 
xlabel(’Burnup’) 

figure 

plot(burnup,test_clad_strain(:, i))/ 
hold on ” 

for i=2:NUM_STEPS-l 

plot(burnup,test_clad_strain(:,i),'-k*); 
end ^ 

plot(burnup,test_clad_strain(:,NUM_STEPS),*-r’); 

title(’Clad Percent Strain vs Burnup*) 

ylabel(’Percent Clad Strain*) 

xlabel(’Burnup*) 

hold off 

figure 

plot (burnup, test_fiss_gas_rel (:, i)) ; 
hold on * 

for i*2:NUM_STEPS-l 

plot(burnup,test_fiss_gas_rel(:,i),*-k *); 
end “ - - 

plot (burnup, test_fiss_gas_rel (: ,mjM_STEPS), * -r') ; 
title(*Percent Fission Gas Release vs Burnup*) 
ylabel(’Percent Fission Gas Release') 
xlabel{* Burnup *) 
hold off 

figure 

plot(burnup,test_gap(;,i)>; 
hold on 

for i*2:NUM_STEPS-l 

plot(burnup,test_gap(:,i),’-k *); 

end 

plot (burnup, test_gap (:, NUM_STEPS), * -r *); 
title('Gap Size vs Burnup*T 
ylabelCGap Size (mills)’) 
xlabel(’Burnup’) 
hold off 

figure 

plot(burnup,test_gap_cond(;,i)); 
hold on 

for i*2:NUM_STEPS-l 

plot (burnup,t€St_gap_cond( :,i),*-k*); 
end * 

plot (burnup, test_gap_cond (:, NOM_STEPS), * -r *); 
title('Gap Conductance vs Burnup’) 
ylabel(’Gap Conductance (W/m^2“K)*) 



xlabel(* Burnup’) 
hold off 


Modifications to FRAPCON 

Some minor modifications to the FRAPCON source code were required to allow for 
the script-based interface. These modifications are all centered around the requirement to 
organize key output data in a format that is convenient both for transfer into the Matlab 
workspace context, and for parsing the numeric data for subsequent analysis. 

As with the Matlab-VIPRE interface, the most convenient form for the output data, 
firom the perspective of the scripted interface, is for all of the key data to exist in tabular 
form in a ASCII text-file. The key properties of this file are that: 

• There are only numbers, no text 

• The numbers are arranged into rows. Each row must have the same number of 
entries.** 

With the output files in this format, the data can be loaded into the Matlab workspace 
with a single command, and the data can be parsed in a relatively straight-forward 
manner. 

The second requirement listed above dictated that there must be four additional 
output files produced. The idea, during the development of this interface was that: tiiere 
are certain tables of particular interest in die ouqiut file. A single ouqiut file would be 
dedicated to capturing the output that would otherwise go to the particular table of 
interest. If there is another table that is interesting, an additional ouqiut file would be 
established as the repository for this data. This methodology also simplified the logic 
required for the subsequent data parsing.** 

The additional files created are named: 

• Stusum.txt 


** E.g. It is not permissible that the first row have 6 entries, while the second row has only 5. 

‘ Only one t^le format would have to be extracted from the data file. If the table is printed, for example, 
every power-step, the number of power-steps is a known quantity, therefore the table was printed in the 
outyut file a known number of times. This gives the programme complete knowledge of fee structure of a 
given output file based on a simple parameter - for feis example, fee number of power-steps. If there were 
more than one table printed to fee same iiq>ut file, fee tables may not have bear printed in an entirely 
predictable feshion. This would complicate fee parsing-routine logic, and is feus undesirable. 
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• Stusuin2.txt 

• Stusiim3.txt 

• Stustraiii.txt 

They are created with the following code, added to the source file: iofiles.f: 


open(unit=7,file='stusum.txt',status='ncw',fomi-fonnatted') 

open(unit=8,file=’stustram.txt’,status=’new’,fonn-fonnatted') 

<q?en(unit==9,jBle=^stusuin2.txf,status==^ew',form-fonnatted') 

open(uiut=10,file='stusuin3.txt',status=^ew*,fonn='fonnatted’) 


In the source file print2.f, the following changes were then required to capture the 
output: 


if (miiiits.eq.l) write (7,990) iit,aaa(l)Jpeakl 

,(aaa(0,i=2,7),(a^i)4=9,18),a^8),aaa(19),aaa(20) 
if (minits.eq.O) write (7,1000) iiMaa(l)Jpeakl 

,(aaa(iXi=2,7),(a^i),i=9,18),aa^8),aaa(19),aaa(20) 

990 fonnat (i3,lx,f6.1,lx,i2,2x,f7.2,f6.2,lx,3(f7.0),£5.2.1x 

+3(f7.0),lx,«.0,lx,f7.0,lx,fl0.0,fl0.4,fl0.5,lx,f7.0,lx,f5.0,lx,f5.1 

+46.2,lx,f6.1) 

1000 fonnat (i3,lx,f6.1,lx,i2,2x,f7.2,fl5.2,lx,3(f5.0),f52,lx 
+,3(f5.0),lx,«.0,lx,f7.3,lx,f7.3,f7.4,lx,f8.6,lx,f7.0,f6.3,lx,f5.1 
+,f6.2.1x,fiS.l) 

IfoUowmg lines added to extract output data for stustraiatxt 
write(8,l 100) denimXdairmc 
1100 f(Mniat(fll.5,2x,fll.5) 

wrile(8,l 110) swlrml, swirmc 
1110 fonn^fll.5,2x,fll.5) 

write(8,1120) expr^exprmc 
1120 fonii^fll.5,2x,fll.5) 

write(8,l 130) relocm^’elocs 
1130 fonn^fll.5,2x,fll.5) 

! write(8,l 140) rco, rcom 
1140 fbniK^fll.5,2x,fll.5) 

write(8,l 150) creapl, creapm 
1150 fonn^fll.5>,fll.5) 

write(8,l 160) expnrl, expnrm 
1160 fonnal(fll.5,2x,fll.5) 

write(8,l 170) totcrl, totcnn 
1170 fonnat(fll.5,2xfll.5) 


write(9,1910)iml,a(lcn2h2+iml-l),a0cexh2+iml-l),epsunp,oxmib 
+ ,oxmicr, a(lfluen+iinl), fingrpct 



1910 format(i3,6x,f82,8x,f8.2,6x,fl5.3,9x,f6.4, 

+ lx,f7.3,7x, elO.4,7x, flS.2) 

write (10,891) nnl,tfik,a(ltmpds+ij),rt)ari!;,a(ltbar4-iml),tcak,a( 

+ ltca+iml),tblkk,tt>lkf,q)dltx,eppra,epphpi,epphpo,q)pax,epgro 
891 fonnat (i2,3x,2(f7.1,2x,f7.1,2x),2x,f5.0,2x,f5.03x,f 
+5.0,2x,f5.0^x,lpe8^,8x,Opf5^3x,6.2,3x,6.2,2x,C.2, 

+4x,f5^) 









Appendix 8 RELAP Interface 


The Matlab-VIPRE-RELAP Interface is not finished, but some of the key tools are 
put in place. A schmatic view of the interface is provided in Figure 44. The basic form of 
the Matlab-VIPRE Interface is left intact. The difference is that boundary-condition data 
for transient analysis is passed ftirough the file system from RELAP to VIPRE. As with 
the Matlab-VIPRE Interface, all of the movement of data and coordination of operations 
takes place wiftiin the Matlab environment. 
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F^re 44: Schematic representation of the Matlav-VIPRE-RELAP Inter&ce. 


The interftice, to the extent that it is functioning at the time of this writing, has as a 
prerequisite a valid RELAP input deck for the particular transient that is of interest. 
Modifications have been made to the RELAP source code such that a separate output file 
is produced that has, without any other adornments, the ‘minor edits’ as specified in the 
input deck. 

The two main methods of output from the RELAP program is through so-called 
‘Major Edits’ and ‘Minor Edits’. The major edit is, put briefly, a ‘dump’ of the status of 
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every component of the RELAP model. This is a large body of information diat, w bil ft 
presenting a great deal of data to the user, is difficult to use due to the vast quantity of 
information displayed. The major edits are output at intervals (as determined by die 
number of discrete time steps taken within the simulation) set by the user in die input 
deck. 

The minor edits are specific bits of data that are requested at intervals that are 
generally shorter than the major edits. For the simulation, there may be particular 
quantities that the analyst may like to keep a close eye on - for example, die core inlet 
mass flow rate. The user would direct this value to be ouqiut as a minor edit—which is 
generally a much smaller quantity of data dian what is provided with the major edit, and 
allowrs the desired information to be found within the output file more quickly and, 
provided die minor edits are output at shorter intervals than die major edits, die data 
among the minor edits will have sharper temporal resolution. 

The portion of the source code that writes the minor edits to the usual output file has 
been modified so as to send this same data (though without data labels, or textual 
information of any kind - only numbers are allowed) to an ordinary ASCII text file diat 
can easily be loaded and parsed by a relatively simple Madab Script The modified 
portion of the RELAP source code is given here: 


^define win32<ivf 
*defineerf 
♦define foiutyt 
♦define hconden 
♦define impnon 
♦(tefine m32 
♦define newnre 
♦define ploc 
♦define ^haccro 
♦define Unix 
♦define noselap 
♦define noextvol 
♦define noexhr20 
♦define noextsys 
♦define noex^un 
♦define nocx:ti20 
♦define noparcs 
♦define nonpa 
♦define noouq) 

♦define lo^ 

♦deckmirec 

subroutine mirec 

c Sid: mirec.flEv 1.12001/02/01 23:17:28 r5qaE?qp dbaibcrS 
c 

c mirec transfers results of time step to save area for minor edits and 
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c edits die infonnation if save area is full, 
c 

c Cognizant engineer gw. 
c 

implicit none 
include 'comcd.h' 
include 'contrlh' 
include 'fast.h' 
include *miedtc.h' 
include *ufUes.h' 
c 

c Local variables. 

integer i,ixj,IUla,12,12x,1343x,l4^iMil 

integer istu 
istu=69 
c 

c Get packed quantities to control store of results. 
ll=filndx(16) 
m“inipck(2,Il + 4) 
n = mipck(2,ll) 

B = mipdc(2,ll + 3) 
if(done)21^^3 
23 if (m .ne. 0) go to 16 
return 

21 done-"done 

22 lla==impck(241+l) 

12 = 13 + m*n 

c Store results into save area. 
dol5i-l^ 

11 mikold(12) = fa(micodc(2,ll+l)) 

12 if(unito)goto 14 

if (miconvOl) .It. O.OdO) go to 13 
mflK>ld02) = mihold(12)*miconv(ll) 
goto 14 

13 mihold(12) = (mihold(12)+miconvfll))*1.8d0 

14 11 =11 +11a 
12 = 12 + 1 

15 continue 

c Increment number of edits and test if save area is full. 
m=m+1 

if (m .ne. 50) go to 100 
c Edit accumulated minor edit data 

16 lla=9 
12 = 13 
nl =n-1 

14 = mipck(2^dx(16) + 2) 

19 if(nlJt9)lla=nl 
ix = l4 + (lla-l)*8 

write (ouq)ut^001) (milabl(j) 4 nflabl(j+l) j=14,ix,8) 


2001 formatCl time',8x,9(a8,a5)) 

write (ou^ut^003) (milabl(j+2)^abl(j+3) j=14,ix,8) 

2003 fOTBiatC (sec)’,7x,9(a8,a5)) 

write (ou^uU004) (i!iilabl0+4)^abl(j+5) j=14,ix,8) 

2004 format (15x,9(a8,a5)) 

write (oiitput^004) (milablO‘+6),milabl(j+7)J=14,ix,8) 


I2x = 12 
13x = 13 
do 20 i = 1^ 
ix = 13x + lla-1 

write (output^002) mihold(l2x),(mihold0+l) j=13x,ix) 


Extract minor edit data with this line 






wnte(istii^002) mihol<l(l2x)XmiholdO+l)j»13x,i^^ 
2002 foiinat(lp,gl4.6,9gl3.5) 

12x = 12x + ii 
Dx-Dx + n 
20 continue 
13 = 13 + 9 
14=14 + 72 
nl»nl-9 
if(nl .gt0)goto 19 
m = 0 
c 

100 impck(2^dx(16>+4)«in 
return 
end 

c 

c Data dictionaty for local variables 
c 

c Number of local variables = 13 


c Hntcgcr i-real Wogical c*character 

cType Name Definition 

c- 


IX = 

j 
11 

11a = 

12 

12x = 

13 
I3x 

14 

m = 

n = 

nl 


Note that the file with unit designation ‘69’ is opened in a different portion of the 
source code and represents tiie text file “stuouttxfOne should also note that, with the 
modification implemented in this way, if more than nine variables are requested to be 
ouq>ut with the minor edits (or as would be said; . .if more than nine minor edits are 
requested...”) the modification will fail. The code will output the minor edits using a 
maximum of nine columns. That is, if more than nine minor edits are requested, there 
will be two separate ‘blocks’ of minor edit data printed to the output file (and thus to 
‘stuouttxt’). This is a problem because the Matlab code used to parse the results stored 
in ‘stuouttxt’ requires; 
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1. That each row have the same number of colums - If there are more than nine 
mino r edit requests, this would only be true if die number of minor edit requests is an 
integer multiple of nine. Failure of this condition will cause Matlab to report an error.® 

2. The parsing script assumes that each row of numbers corresponds to the complete 
set of minor edits for a given time step. If there is an integer multiple of nine minor edits, 
and dius Matlab is able to load the contents of the file into the woricspace context, there 
would still be a logical error in the parsing script in that only a fraction of the data would 
be parsed, and only the first block of data would be parsed correctly. 

Note diat die second requirement could be eliminated by making changes to the data 
parsing code. It is eiqpected that as the needs of the analysts change, this parsing script 
will also be changed. 

This is the current state of the RELAP interface. Once a satisfactory RELAP input 
deck is created and modified to output the appropriate minor edits for input to VIPRE 
(core power, system pressure, core inlet flow rate, core inlet coolant temperature and 
transient time) it will be left to modify die input data extraction scripts firom the Madab- 
VIPRE Interface for transient input (i.e. get_excel_input_trans.m - or one of the variants 
therof such as get_excel_input_trans_w31.m) so that the transient forcing ftmction data is 
extracted from the RELAP ouput file stuouttxt, rather from a sheet within the Excel 
workbook as is currendy done. 


* When using die ^loaiifilenamey widiin the Matlab environment, Matlab requires that each row of 
numbers contains the same number of columns of data. 
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Appendix 9 IRIS Open Core Fuel Cycle Analysis 

Introduction 

The economic attractivness of a given design is, with the exception of safety, 
probably the most important discriminator between different designs. In this appendix, 
an economic evaluation of the fuel cycle cost is conducted for the IRIS Open core. This 
fuel cycle cost analysis takes into consideration the following cost components: 

• Uranium purchase, conversion and enrichment costs; 

• Fuel fabrication cost; 

• Replacement Energy Cost during (platmed and implanned) plant shutdowns; and 

• An estimate of O&M costs during planned plant shutdowns. 

IRIS Open Model 

To perform an economic analysis of the IRIS fuel cycle, several core design inputs 
are required. These inputs are summarized in Table 19. 


IRIS Open Core Design Inputs 

Thermal Power 

1000 MWth 

Electric Power 

335 MWe 


48.5 Metric Tons Uranium 

Fuel Enrichment 

4.95 % 

Single Batch Discharge Bumup 

38,000 MWd/Ton Uranium 


Table 19: IRIS Core Design Parameters. 


To allow for fuel management strategies other than the single batch “straight bum”, 
the Linear Reactivity Model was applied to determine discharge bumup for N batches. 
The discharge bumup is then estimated by the following equation: 

Equation 27 


^^disdiarge ^^1-balch 


2N 

'{N+l) 


The following assumptions were made regarding plant operation and maintenance 


schedules: 
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_ IRIS Operation and Maintenance Parameters _ 

Refueling Outage Length _ 15 Days _ 

Forced Outage Rate _2%_ 

Table 20: IRIS O&M Parameters. 

Economic Model 

The methodology applied for the fuel cycle calculations is based on the levelized, 
lifetime cost method in accordance with OECD/NEA recommendations.^'*^^’^^®^ All front- 
end fuel cycle costs and future revenues are referred to the be ginning of irradiation. The 
value of these front-end costs and future revenues are calculated assuming: 

• Front-end costs occur prior to the beginning of irradiation according to the 
schedule given in Table 21, 


_ Front-end Transaction Lead Times _ 

Transaction_ Lead Time (months^ 



Uranium Purchase 
Uranium Conversion 
Uranium Enrichment 


Table 21: Fael Cycle Front-end Pnrcbase Lead Time, 
a The unit cost for the front-end expenditures are listed in Table 22. 


Front-end Unit Prices’’ 

Uranium Purchase 

27.7 $/kgU 

Uranium Conversion 

4.9 $/kgU 

Uranium Enrichment 

108 $/kgSWU 

Uranium Fabrication 

200 $/kgU 


Table 22: Unit Prices for Front-End Transactions. 

• Remaining Parameters relevant to the fuel front-end are listed in Table 23. 


* Prices quoted were obtained at; http'7/www.uxc.com/review/uxc prices.html — a page fiom the Ux 
Consulting Group LLC website. 






















Additional Parameters 


Uranium Feed Enrichment 

0.71 % 

Tails Enrichment 

0.3 % 

Discount Rate 

8% 


Table 23: Front-end Cost Parameters. 


These assumed parameters were then applied to the following economic model; 


Front-end Cost Calculation 

The front-end fuel cycle costs of Uranium Purchase, Uranium Conversion, Uranium 
Enrichment and Fuel Fabrication are computed individually and compounded linearly to 
determine their worth at the beginning of fuel irradiation. 

Uranium Cost 

The natural Uranium required as an input to the nuclear fuel manufacturing process 
is computed as a cost per kilogram according to the following equation: 


Equation 28 


$ 


Start of irradiation 


kg 


feed 


kg 


fuel product 


kg 


fuel product 


kg 


■•(i+xAr. 


uranium purchase} 


feed 


Where: x is the discount rate 

AT is the required lead time 

The quantity of feed required per quantity of fuel product is found as the following 
function of fuel enrichment, feed enrichment, and tails emichment: 


Equation 29 

F ^ Xp-x, 
P Xf-X, 


Where: 

F 

— = mass of feed per unit product 

Xp = fuel (product) weight fraction 
Xf = feed weight Action 
Xt = tails wei^t fraction 

Fuel Conversion Cost 

The fuel conversion cost is computed as follows: 
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Equation 30 


aan of inadiaion _ feed ^ ^conversion . J 

^Sfuet product fuel product feed 

Fuel Enrichment Cost 

The enrichment costs are computed as follows: 


uranium ctmversion j 


Equation 31 


^ Start of irradiation cirrrr r $ 

"7 -- oIrU -- 


9 fuel product 


swu 


’l^ + xAT 


fuel enrichment j 


Here, the amount of SWU (separative work units) required is computed as 


follows: 


Equation 32 


=^= [v{p)-V{fi-h-lL. [V{f)-V{!l 

fuel Xf 


Xf-X, 


Where: 


r0>)=(2jt,-l)ln^ 

1 —X 

P 

r(f)= {2x,-l)in:^ 

1 Xj 

r(()=(2x,-i)to-^ 


Fuel Fabrication Costs 


The fuel fabrication costs are computed as follows: 

Equation 33 

of Irradiation _ ^fabrianlon ("I Ay ) 

"’Sfiul product fuel 


Total Fuel Front-end Costs 

The total fuel front-end cost is the sum of the costs for the mined uranium, uranium 
conversion, enrichment and fuel fabrication: 
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Equation 34 

lo = Urmium Purchase Cost + Conversion Cost + Enrichment Cost + Fabrication Cost 


Levelized Fuel Cycle Cost 

The present worth of the continuous revenue stream from sale of electricity is: 

Equation 35 

$ 


B 

” 1000 


^Ifcc-p’L-r]-e~^dt 




m 


Where: 


8766 _ hr/year 
1000 mills!% 


= core residence time of a fuel assembly (years) 

kW 1 


Ifcc = levelized fuel cycle cost 
T 

p = specific power 

L = capacity factor 


mills 

kW. 




OA 


= Ihermodynainic efficiency 


fel 

[kW,\ 


1-e 


-xT 


Formally Equation 35 is solved to equal: 

Equation 36 

Eg =%.166'lfcc-p’L-rj- 


To find the value for levelized fuel cycle cost, Equation 36 is equated to the value of 
the front-end costs at the beginning of irradiation (Equation 34). The levelized fuel cycle 
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cost is the cost at viiich the front-end costs, and the continuous revenue stream from 
electrical generation are made equal: 


Equation 37 


lfcc = 


h 1 

X 

8.766-*7 



Since the fuel discharge bumup can be computed as: 


Equation 38 


365 dayslyear 

mo 


Equation 37 can be equivalently expressed in the some>^at more convenient form: 

Equation 39 


lfcc = 


h 1 

xT 

_S.766‘Bu’TJ 

U-e-^\ 


To perform the actual computation, an expression is also required for the specific 
power (p) and capacity factor (L). 

From a complete core design, the specific power can be computed simply as the 
ratio of the core themal power (in kWth) to the heavy metal loading (in kilograms).*’ The 
capacity factor is e7q)ressed as follows: 


Equation 40 


Where: 

V 


Tr 


i=r 



= Plant availability = 1 - Forced Shutdown Rate 
= Length of Refueling Outage (days) 


* This actual computation can be complicated to some degree by die requiiment to account for the 
fobricated fuel density (as compared to fuel theoretical density) and any fuel pellet design features such as 
‘dishing’. A general expressicm for the mass of fuel present as a function of a few key core parameters is 
thus forgone. 



Tc = Length of Refueling Cycle (operating and refueling days) 

For die purposes of diis analysis, the plant availability is an assumed parameter as is 
the refueling outage lengdi. The length of the refueling cycle is dependent on the 
duration of the outage (assumed) and the computed length of operation for a given batch 
witiiin a fuel cycle. The length of operation of a given batch within a cycle is determined 
as a function of the q)ecific power, the forced outage rate and the bumup for a given 
batch. The specific power is computed as described above; the forced outage rate is 
assumed. The discharge bumiqp for a given fuel management strategy (i.e. number of 
batches) is computed using the linear reactivity model in Equation 27. The bumup for a 
given batch within flie fuel cycle is then found by: 

Eqaatton 41 

■n _ ^^dischar$e MW d "1 

" #of Batches J 


Equation 42 


„ ,, 1000 / * \ ^r^AMW\ 

Bu^j^=P‘L - -(l-.02) = 20.6 - 

^ 48.5 '■ ^ L^J 


Therefore 


Equation 43 


Tc M 

per day 


Thus, the capacity factor can be found; which was the last link in the chain required 
to determine the levelized fuel cycle cost. 


Analysis - Front End Costs 

Considering only the parts of the model considered so far, the levelized fuel (tycle 
cost is computed, for a variety of fuel management strategies. In principle, any number 
of batches may be planned for a given fuel cycle. The number of fuel assemblies to be 
removed for each batch is simply: 

^ Some actual values given for the IRIS design considered here. 
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Equation 44 


# Assemblies to Replace Each Re&eling ■ 


# Assemblies In Core 
# Batches 


As a practical matter, an integer number of fuel assemblies must be replaced with 
each batch at the very least. More practically still, the number of fuel assemblies to be 
replaced drould be an integer multiple of 4. The fuel management strategies considered 
in this study are given in Table 24. 




Table 24: Fuel Management Strategies Considered ibr HUS. 
For tiiese strategies, the followiag parameters are computed: 


# Batches 



lESSSSSSSHI 

1.00 

38000 

38000 

1881.16 

2.02 

50857 

25143 

1244.67 

2.47 

64112 

21888 

1083.54 

3.18 

57812 

18188 

900.38 

3.71 

59858 

16142 

799.07 

4.45 

62056 

13945 

690.33 


Table 25: Fuel Management Strategy Parameters. 

Coirsidering only front-end costs, the levelized fuel cycle cost for the fuel 
management strategies presented is given in Figure 45. The parameters used in this 
analysis are summarized below: 
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Parameter 

Value 

Thermal Power 

1000 MWth 

Electric Power 

335 MWe 

Fuel Loading 

48.5 Metric Tons Uranium 

Fuel Enrichment 

4.95 % 

Uranium Purchase Lead Time (months) 

24 

Uranium Conversion Lead Time (months) 

18 

Uranium Enrichment Lead Time (months) 

18 

Uranimn Fabrication Lead Time (months) 

12 

Uranium Purchase Unit Price 

27.7 $/kgU 

Uranium Conversion Unit Price 

4.9$/kgU 

Uranium Enrichment Unit Price 

108 $/kgSWU 

Uranium Fabrication Unit Price 

200 $/kgU 

Uranium Feed Enrichment 

0.71 % 

Tails Enrichment 

0.3 % 

Discount Rate 

8% 

Forced Outage Rate 

2 % 


Table 26: Summary of Parameters for Initial Fuel Cycle Cost Analysis. 


LFCC vs i of Batches 



Figure 45: Levelized Fuel Cycle Cost • Considering only Front-End Costs. 

The above figure clearly shows the benefit to be e3q)ected to fuel cycle costs by 
increasing the number of batches. As shown in Table 25, the discharge bumup increases 
with an increasing number of batches. Therefore, by increasing the number of batches, 
more power is extracted fi'om every kilogram of fuel, thereby increasing the length of the 
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revenue stream from that mass of fuel, thereby reducing cost. The above analysis, 
however, neglects the consideration of the costs associated with each shutdown. 

Analysis -> Total Fuel Cycle 

^ith each plant shutdown a myriad of events must take place. Aside from refueling 
the core, hundreds of maintenance activities that eitiier require plant shutdown, or were 
deferred until the next plant shutdown must be accomplished. Most of these 
considerations are beyond the scope of tiiis analysis. However, an attempt will be made 
to capture some of the features of these refueling shutdowns and incorporate them into 
the model to provide some useM information regarding ov^all costs during a given fuel 
cycle. 

For titis model, replacement energy costs will be considered ejq^licitly, as will an 
estimated shut-down cost. Ad(titionally, some approximations will be made to capture 
the variability of shutdown duration. 

The replacement energy costs are modeled as a flat fee per unit energy. For this 
analysis, the assumed value is: 30 mills/kWhr. This value is then normalized so as to be 
given in terms of mills per kWhr that the power plant itself produces in the following 
way: 

Eqaatton 45 

Replacement Energy Cost = = e, (l - Z) 

Where: 

= marginal cost of replacement energy (mills/kWhr) 

P = electrical ou^ut of power plant (MW) 

Note, that conversion factors to convert the units of electrical power from MW to 
kW and the fuel residence time from years to days in both the numerator and 
denominator cancel out. 

Additionally, it will be assumed that the cost of every shutdown can be modeled as a 
linear function of shutdown duration. For this model, the relationship is given as: 

Eqnation 46 
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Chitage Cost = $400 Thousand per day 


This value is in addition tot her replacement energy cost, and has been derived from 
the corresponding cost for current loop PWRs. For a 1,000 MWe PWR, this cost widely 
varies and may amount to some $10-25 Million per outage. The assumed $400K/day and 
15 day outage, leading to a total of $6 Million for IRIS, is larger than die value scaled 
down by IRIS installed power (about one quarter of the power of a 4-loop PWR), but it 
was taken as a conservative estimate pending a detailed analysis of the IRIS outage cost 

In a way similar to that of the replacement energy costs, the outage costs are 
normalized so as to be comparable widi the other fuel cycle cost components. This is 
done in accordance with the following equations: 

Equation 47 

(Cost-per-shutdown)/(kWhr per batch) 

The Cost per shutdown is computed using Equation 46. Equation 45 requires the 
length of the shutdown m days which is computed using Equation 48. Equation 48 
requires one to know how many days of operation occurred between refuelings which is 
computed using Equation 41 and Equation 42. 

As an additional measure, the fuel disposal cost of 1 mill/kWhr is added in order to 
make a more full accounting of all fuel cycle related costs. 

The parameters used in this more complete analysis is provided in Table 27 and the 
results are displayed in Figure 46. 
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Parmeter 

Value 

Thermal Power 

1000 MWth 

Electric Power 

335 MWe 

Fuel Loading 

48.5 Metric Tons Uranium 

Fuel Enrichment 

4.95 % 

Uranium Purchase Lead Time (months) 

24 

Uranium Conversion Lead Time (months) 

18 

Uranium Enrichment Lead Time (months) 

18 

Uranium Fabrication Lead Time (months) 

12 

Uranium Purchase Unit Price 

27.7$/kgU 

Uranium Conversion Unit Price 

4.9 $/kgU 

Uranium Enrichment Unit Price 

108 $/kgSWU 

Uranium Fabrication Unit Price 

200$/kgU 

Uranium Feed Enrichment 

0.71 % 

Tails Enrichment 

0.3 % 

Discount Rate 

8% 

Forced Outage Rate 

2% 

Refueling Outage Length 

15 Days 

Shutdown O&M Cost 

$400 K/Day 

Replacement Energy Cost 

30.0mills/kWhr 

Spent Fuel Disposal Fee 

1 mills/kWhr 


Table 27: IRIS Parameters for Refined Fuel Cycle Cost Analysis 


I 

I 


CoftvsfoTBatchM 



F^re 46: Fuel Cycle Costs for IRIS Including Shutdown O&M, Replacement Energy Costs, and 

Spent Fuel Disposal Fee. 


































Sensitivity Study 

Clearly, all of these analyses involve uncertainty with regards to most (if not all) of 
the parameters. It is useful for the engineer to be aware of which of the assumed 
parameters influence the outcome of the fuel cycle analysis the most. For these 
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sensitivity results, each parameter discussed is varied individually. The sensitivity is 
defined as: the percentage change of the total cost* for every percentage change in die 
given parameter. 


Equation 49 



Where: 

e = total cost with one perturbed parameter 
= reference total cost,^ 

c^ — perturbed value of one parameto* 

- reference value of the parameter. 

Natural Uranium Price Sensitivity 



Natural Uranium Price ($/kg Natural Uranium) 


* Total cost includes levelized fuel cycle cost, shutdown O&M - including replacement energy costs, and 
die disposal fee. 

* I.e. aU parameters ar'* at their reference condition. 








Sensitivity (%r»/ci Sensitivity (%««} 


Uranium Conversion Price Sensitivity 



Uranium Conversion Price ($/kg Natural Uranium) 



105 


125 












Sensitivity (%r!^ Sensitivity 











Sensitivity Sensitivity 


Replacement Energy Unit Cost Sensitivity 



Daily Outage Cost Sensitivity 
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Sensitivity 
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For the values of the parameters used in this study, it is seen that the enrichment 
costs, uranium purchase costs, daily outage costs and discoimt rate have the largest effect 
on the overall fuel cycle cost. 

One difficulty that is presented with this sensitivity study, is that the magnitude of 
the sensitivity for a given parameter is dependent upon the re maining parameters in the 
model. For this simple sensitivity study, all other model parameters are held at their best- 
guess values. The problem is that die magnitude of many of the parameter sensitivities is 
dependent upon the other variables. The fuel cycle cost is a function of several variables. 
The sensitivity analysis procedure discussed above is akin to taking the partial derivative 
of the fuel cycle cost fimction with respect to just one of the variables. This partial 
derivative has many different values, depending upon where within the n-dimensional 
domain of the fuel cycle cost function the derivative is evaluated. As an example of this 
weakness, the fuel cycle enrichment cost sensitivity is shown widi assumed discount rates 
ranging from 6% to 11 %. 
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Enrichment Cost Sensitivity 



Enrichment Cost S/kg^ 


Figure 48:IIhistratioii of Variability in Sensitivity. 

There is no way that this difficulty can be eliminated. Furthermore, even if there 
was, any mediodology diat could be used to detennine the overall model uncertainty 
(making use of this sensitivity data) would be unable to capture tbds behavior. This is die 
reason why the MCUP provides more accurate results than the ITDP.* 

Uncertainty Analysis 

It is a fact that all of die parameters under consideration in this study are subject to 
uncertainty. In order to deal with this uncertainty in a logical and consistent &shion, the 
following ^)proach was used which is based on tiie approach used in reference [51]. A 
selection of parameters were assigned a non-parametric probability distribution function 
(PDF). This PDF is formed by selecting a most likely value (mode) for a given 
parameter and a minimum and maximum value diat the parameter is ‘reasonably’ 
eiqiected to take. In this context, the phrase ‘reasonably’ should be interpreted to mean: 
subject to the judgement of a panel of eiqierts. For diis analysis, no such panel was 
assembled, rather die judgment of the author was used in order to arrive at plausible 
values. 

• The Monte Carlo Uncertainty Procedure (MCUP) and Ae Improved Thermal Design Procedure (ITDP) 
are two hot-channel analysis methodologies fliat were used in a thermal-hydraulic analyst of die IRIS core. 




Once the distributions were created for each parameter under consideration, these 
distributions were sampled ten thousand times (each), the cost model was updated with 
the new sample parameters, and the total cost was computed. The statistical properties of 
the output total fuel cycle costs were tiien analyzed. The total cost mean value as well as 
the 5* and 95* percentile were computed and plotted. This process was repeated for each 
of the six fuel management strategies (number of batches). 

The characteristics of the parameter distributions are given in Table 28. 


Parameter 

Minimum 

Mode 

maximum 

*Uranium Purchase Price ($/kgU) 

21.7 

27.7 

50.6 

♦Uranium Conversion Price ($/l^U) 

3.7 

4.9 

6.8 

♦Enrichment Price ($/SWU) 

78.5 

108 

127.7 

♦Fuel Fabrication Price ($/kgU) 

145.4 

200 

254.6 


5 

8 

11 


7 

10 

13 


1 

2 

3 

Daily Shutdown Cost ($/day) 

$200K 

$400K 

$800M 

Forced Outage Rate (%) 

1% 

2% 

3% 

Replacement Energy Cost (mills/kWhr) 

24 

30 

36 

* Based on j)ercentage above or below Mode used in reference [51]. All ofliers are based 
guess. 

on author’s best- 


Table 28: Distributions Used for Monte Cario Uncertainty Analysis of Fuel Cycle Costs. 


The results are presented here: 
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Total Fuel Cycle Cost Distribution > 10000 Samples; 2.4722 Batches 
mean cost = 7.6454 mean 95% limit = 8.5401 


Total Fuel Cycle Cost Distribution 
95% Cost Upper Confidence Limit 




R 



Total Fuel Cycle Cost mills/kWhre 


Total Fuel Cyde Cost Distribution -10000 Samples: 3.1786 Batches 
mean cost» 7.5961 mean 95% limit = 8.5217 


Total Fuel Cycle Cost Distribution 
95% Cost Upper Confidence Limit 


B 



Total Fuel Cycle Cost ivHits/kWhre 
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Prabtbitily OtfitAy 



Tclat Fu«t Cycii Cott Distribution • 100D0 SamplM: 4.45 Batchot 
« 7.B905 mtan 95% linijt = B.652S 



7.5 8 as 

Total Fuat Cyda Coat mit/kWhre 
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Total Fuel Cycle Cost - with Uncertainty 



F^are 49: Total Fuel Cycle Cost Monte Carlo Analysis Results. 

It is notable that, for many of the batches, the results are slightly skewed from 
normal. This is judged to be due to the non-symmetry of the probability distributions of 
some of the important parameters, notably: fuel enrichment unit cost, and daily refueling 
outage costs. 

Conclusions 

The results of this analysis indicate that a fuel management strategy where 2 to 3.5 
batches are used would be the most economically attractive from a fuel cycle cost 
perspective. Higher costs are expected to occur for the single-batch ‘straight bum’ 
option, and also for strategies that involve more than 4 batches. These results are 
consistent with the common industry pratice of using a 2 to 3-batch fuel management 
strategy. 

It is emphasized, however there is a considerable amount of uncertainty inherent in 
some of the model parameters used, particularly those parameters pertaining to operation 
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and maintenance (O&M) costs. While reasonably direct and unambiguous data^ exist 
with regards to the fiont-end costs, nothing of the sort is available for the O&M costs. It 
is e}q)ected that the O&M costs for the ERIS core will be positively affected by reduced 
requirements for: 

• Weld inspections (fewer welds are required due to the integral vessel design), 

• Reactor coolant pump inspection (maintenance-free spool pumps are adopted) 

In addition, ongoing efforts to optimize maintenance on critical plant components^^^^ 
(e.g. Turbine Generator Governor testing, pressure relief valve testing, main condenser 
waterbox cleaning) are expected to reduce the downtime requirement for shutdown 
inspection and maintenance. However, this potential cost reduction has not been 
accounted for in the present analysis. If the assumed values are greatly in error, tire 
impact on the results could be significant: on the order of 2 - 3 mills/kWhre and, because 
of the flat shape of the curve in Figure 49 could completely change the resulting optimum 
fuel management strategy. At the same time, tire absolute difference in the cost will 
likely remain small, and therefore the impact of using a non-optimum scheme may be 
acceptable. 

Matlab Code 

To document the calculations done, the Matlab code used for the analy sis is provided 
here. 

All of the parameters used in the ecomnic model are stored in a Matlab ‘struct 
array’.‘ This data structure is initialized with the script below: 


%inltiali 2 e model.m 


% ASSUMED/ASSIGNED PARAMETERS 

model.thermaljpower « 1000; %MWth 
model.electrxcjpower « 335; %MWe 
model.assemblies = 89; 

% FUEL RODS PER^ASSEMBLY « 264; 

% ACTIVE_CORE HEIGHT * 14; 


^ As well as qiecification 1^ flie OECD guidelines in the case of front-end fuel cycle costs. 

' This data ty^ is similar in syntactically and semantically similar to the data structure (called ‘struct’) in 
the C programming language. 
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% AVERAGE_LIKEAR_POWER =* 3.04; %kW/ft 
% PELLET^DIAt-dETER = 0.3225; %in 

% FUEL_DENSITY = 0.96; %fraction of theoretical density 

% FUEL DISKING = .01; %fraction dishing 

% HM_PER_ASSEMBLy = 545.1; %kgU/FA 

model.fuel_loading= 48.5e3; %kg U/core 

model.forced_outage_rate =0.02; 

%model.refueling_outage_l€ngth = 30; %days 

model.feed_enrichment = 0.00711; %weight fraction of 0-235 

model.tails = 0.003; %welght fraction of U-235 in tails 

model.uranium_j)urchase_lead_time = 24; %months 

model.uranium_conversion_lead_time = 18; %months 

model.nrani\im__enrichment_lead_time = 18; %months 

model.uranium_fabrication_lead_time = 12; %months 

model.uranium_purchase_cost = 27.66; %$/kgO 

model.urani\im_conversion_cost = 4.90; %$/kgU 

model.swu_cost = 108; %$/kgSWU 

model.fuel_fabrication_cost = 200; %$/kgD 

model.discount_rate = 0,08; 

model.fuel_enrichment = 0.0495; %weight percent U-235 in fuel 

model.replacement_energy_\mit_cost = 30.0; %miils/kW-hr 

model.outage_daily_cost = le6; %doliars 

model.disposal_fee = 1.0; %mills/kWhre 

model. single_batch_discharge_burnup = 38000; %iyrwd/tU 

model.batches =1; 

model.itdn_shutdovm_length =15; %days 

model.variable_shutdown_length =5; %days/burnup-year 

% ASSUr^ED/ASSIGNED PARAMETERS 


The total fuel cycle cost is computed with the following function: 


%calc__costs .m 

function [ Ifcc, repl_energy_cost, disposal_fee, shutdown_o_and_jn, capacity_factor] 
calc_costs (model); 

% ASSUMED/ASSIGNED PAPJUffiTERS 

THERMAL_POWER = mode 1. the rmal_power; 

ELECTRIC_NET = model.electric^power; 

ASSEMBLIES = model.assemblies; 

FDEL_LOADING = model.fuel_loading; 

FORCED_OUTAGE_RATE = model.forced_outage_rate; 

FEED__ENRICHMENT = model. feed_enrichment ; 

TAILS = model.tails; 

U_PURCHASE_LEAD_TIME = model.uranium_purchase_lead_time; 
U_CONVERSION_LEAD_TIME = model .uranium__conversion_lead__time; 
U_ENRICHMENT_LEAD_TIME = model. uranium_enrichment__lead_time; 
0__FABRICATION_LEAD_TIME = model .uranium_f abrication_lead_time; 

U_PURCHASE_COST = model .urani\am__purchase_cost; 

U_CONVERSION_COST = mode1.uranium_conversion_cost; 

SWD_COST = model, swu^cost; 

FUEL_ASSEMBLy_FABRICATION_COST = model. fuel_fabrication_cos t; 

DISCOUNT^RATE = model.discounterate; 

FRESHeFUELeENRICHMENT = model. fueleenrichment ; 

REPLACEMENTeENERGYeUNITeCOST = model .replacement_energyeUniteCOSt; 

DAILYeLABOReANDeMATERIALSeCOSTeOFeOUTAGE = model.OUtageedailYeCOSt; 

SINGLEeBATCH_DISCHARGEeBURNUP = model. single_batch_dischargeeburnup; 
DISPOSALeFEE = model .disposalefee; 

BATCHES = model.batches; 

MIN_REFaELING_OUTAGE_LENGTH = model .mineShutdownel ength; 

VAReSHUTDOWNeLENGTH = model .vari ablets hut down^l eng th; 

% ===== ASSUMED/ASSIGKED PARAMETERS ===================================«*.* 

specific_j)Ower = (1000*THERMALePOWER)/FUELeLOADING; %kWth/kgU 
thermaleefficiency = ELECTRICeNET/THERMALePOWER; 
plant_availability = 1.0-FORCEDeOUTAGE_RATE; 














num fresh fa_j>erjbatch • ASSEMBLIES/BATCHES; 

Clischarge“bumup « SINGLE_BATCH_DISCHARGE_BURNUP* (2*BATCHES) / (1+BATCHES) ? %MWd/tl3 
bumupjper^batch « discharge^burnup/BATCHES; %MWd/tU“batch 
dailyjburnup * specificjpower*plant_availability; %MWd/tO-day 
bumup lengthjper__batch ■ burnup_j>er_batch/daily_burnup; %days 
REFaELING_OUTAGE_LENGTH - MIN_REFDELING_OUTAGE LENGTH + 
(VAR_SHCrTDOWN_LENGTH*bumup_lengthjper_batch/365.25) ; 

refueling_cycle_length * REFOELING_OUTAGE_LENGTH + burnup_length_per_batch; %days 
capacity_factor » plant_availability*(1 - 
REFOELING_OUTAGE_LENGTH7refueling_cycle_length) ; 

kwhrejper^batch • 1000*ELECTRIC_NET*capacity_factor*burnup length^per batch*24; %kf?hre 
COSt_per shut_dOwn « DAILY_LABOR_AND_MATERIALS_COST_OF_OUTAGE* ... 

REFUELING_OUTAGE_LENGTH; ^dollars 
fuel_residence_time * refueling_cycle length ♦BATCHES; 

F R » (FRESH_FOEL_ENRICHMENT - TAILS)?{FEED_ENRICHMENT - TAILS); 

Vjp “ (2*FRESH FOEL^ENRICHMENT - 1) ♦logCFRESH^FOEL ENRICHMENT/(1-FRESH_FUEL_ENRICHMENT)) ; 
V_f = (2*FEEDjENRICffiffiNT - 1) ♦log (FEED ENRICHMENT/Ti-FEED_ENRICHMENT) ) ; 

V_t « (2^TAILS - 1)♦log(TAILS/(I-TAILST); 

F * F_P ♦ FUEL LOADING; %kg - mass of feed material needed 

SWU « (V_p-V_tT - ((FRESH FUEL ENRICHMENT - TAILS) / (FEED_ENRICHMENT - TAILS) )*(V_f - 
V_t) ; 

start_of_irr_ore_cost ■ 

(F_P) ♦ (U_PURCHASE_C0ST) ♦ (1+DISC0UNT_RATE* (U_PURCHASE_LEAD_TIME/12)); 
start_of irr_conv_cost - 

(F P) ♦ (U^CONVERSION^COST) ♦ (l+DISCODNT_RATE* {U_C0NVERSI0N_LEAD_TIME/12)) ; 
start_oOrr_enrich_cost « SWU* (SWU^COST)^ (l+DISCOUNT_RATE* (U_ENRICHMENT LEAD TIME/12)); 
start of^irr^fab^cost » (FDEL^ASSElffiLY FABRICATION_COST) ♦ 

(l+DISCOUNT_RATE* (U_FABRICATI0N_LEAD_TIME/12) ) ; 

I_p = start_of_irr_ore_cost + start_of_irr_conv_cost + start_of_irr_enrich_cost + ... 

’’ start_of_irr fab_cost; ~ 

Ifcc - (I _0 * DISCOUNT^RATE 

) / (8.766^specific_power^capacity_factor^thennal__efficiency*... 

(1-exp (-DISCOUNT_RATE^ (fuel_residence_time/365.25)))) ; 

required_replacement_energy - (ELECTRIC_NET • 1000) ♦ refueling_cycle_length ♦ (1 - 
capacity_factor) ♦ (24); 

annualized_replacement_energy_cost * required__replacenient_energy • 

({REPLACEMENT_ENERGy_UNIT_COST/1000) /... 

(refueling_cycle_length/365.25));%last part converts days to years 
ann_energy_cost « annual!zed_replacement__energy_cost; 

repT_energy_cost * ( l-capacity_factor ) ♦REPLACEMENT_ENERGY_UNIT_COST; %mills/kwhre 
shutdown_o_and_ia * (costjper_shut_down/kwhre_perjDatch) ♦ (1000); %itdlls/Jcwhre 
disposal_fee = DISPOSAL^FEE; 


The Monte Carlo analysis requires flie ability to ‘invert’ the triangular probability 
distributions used for the uncertain parameters, in the sense tiiat, in effect, a cumulative 
distribution function is created. The distributions were described only by die mode, 
minimum value and maximum value. Based on this information, and the knowledge that 
the distribution is triangular, a fimction is required that, when given a number in the 
range of 0 to 1, a value is returned that corresponds to the result from passing the input 
number to the cumulative distribution function. This is required to provide the parameter 
sample values for the Monte Carlo Analysis. The function to perform this task is 
provided here: 


%invert tri dist.m 






function val = invert_tri_dist(tri_dist,prob) 

h = 2/(tri_dist.high - tri_dist.low); 

area_to_mode = (1/2)*{tri_dist,mode - tri_dist.low)*h; 
slope_up = h/(tri_dist.mode - tri_dist.low) ; 
slope_down = h/{tri_dist.high - tri_dist.mode); 

if (prob == area_to_mode) 
val = tri_dist.mode 
elseif{prob < area_tojnode) 

val - sqrt(2*prob/slope_up) + tri_dist.low; 
else %prob > area_to_mode 

val = -sqrt(2*(1-prob)/slope^down) + tri_dist.high; 
end 


With tile above function, the resulting Monte Carlo Analysis script is fairly straight¬ 
forward; 


%inc_f cc_analysis .m 
initial!zejmodel; 

Initialize the Probability Distributions ====== 


% same percentage change as KAERI paper ======= = === 

u_cost_dist.mode = model.uranium_purchase_cost; 
u_cost_dist.low = (1-.215)*u_cost_dist.mode; 
u_cost_dist.high = (1.826)*u_cost_dist.mode; 

u_conv_dist.mode = model.uranium_conversion_cost; 
u_conv_dist.low * (1-.25)*u_conv_dist.mode; 
u_conv_dist.high = (1.38) *u_conv__dist. mode; 

u_enrich_dist.mode = model.swu_cost; 
u_enrich_dist.low = (1-.2733)*u_enrich_dist.mode; 
u_enrich_dist.high = (1.182)*u_enrich_dist.mode; 

u_fab_dist.mode * model. fuel_fabrication_cost; 
u_fab_dist.low = (1-.273)*u_fab_dist.mode; 
u_fab_dist.high = (1.273)* u_fab_dis t. mode; 

% ^=s===s^==s=^ my swags =============================== 

disc_rate_dist.mode = model.discount_rate; 
disc_rate_dist.low = disc_rate__dist.mode - .03; 
disc_rate_dist.high = disc_rate_dist.mode + .03; 

sd_length_dist.mode * model .min_shutdown_length; 
sd_length_dist.high = 20; 
sd__length_dist.low = 10; 

var_s d_length__di s t. mode = model, var i abl e_shutdown_length; 
var_sd_length__dist. low = (1-0.5) *var_sd_length_dist .mode; 
var_sd_length_dis t.high = (1.5)*var_sd_length_dis t.mode; 

var_sd_cost_dist.mode = model.outage_daily_cost; 
var_sd_cost_dist.high = (2)*var_sd_cost_dist. mode; 
var_sd_cost_dist. low = (0.5) *var_sd_cost__dist.mode; 

repl__eng_cost_di St.mode = model.replacement_energy__unit_cost; 
repl_eng_cost_dist.low = (1 - 0.20)*repl_eng_cost_dist,mode; 
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forced_out_rate_ciist .mode • model. forced_outage_rate; 
forced_out_rate_dist.low * (1 - 0.5)*forced_out_rate_dist.mode; 
forced_out_rate_dist.high ■ (1.5) *forced_out_rate_dist.mode; 

aU_batches « [1 (89/44) (89/36) (89/28) (89/24) (89/20)]; 
for batch_space “ 1:6 

model.batches * all_batches(batch_space); 

NUM_SAMPLES « 10000; 

sample_lfcc - zeros (NUM_SAMPLES, 1); 

% rand('state*,0); %for de-bugging 
sauries * rand{NUM_SAMPLES, 11) ; 

for j « 1:NUM_SAMPLES 

model .uraniumjpurchase^cost *= invert_tri_dist (u^cost^dist, samples (j, 1)) ; 
model.uranium_conversion_cost * invert_tri_distlu_conv_dist, sairples (j,2)); 
model. swu_cost = invert_tri_dist (u_enrTch_dist/ samplesTj # 3)); 
model. fuel^fabrication^cost""- invert_tri_dist (u_fab_dist, samples (j,4)); 
model.discount_rate - invert_tri_dist (disc_rate~dist,sait^les(j,5)) / 
model.replacement_energy_unit_cost ^ 
invert_tri_dist (repl_eng_cost_dist, saii?>les {j, 7)); 

model - f orced_outage_rate • invert_tri_dist (f orced_out_rate_dist, sauries {j / 8)); 
model.min_shutdown_length » invert_tri_dist(sd_length_dist,samples(j,9)); 
model.variable_shutdown_length * 
invert_tri_dist (var_sd_length_dist, sair 5 )les (j, 10)); 

model.outage_daily_cost • invert_tri_dist{var_sd_cost_dist,samples(j,ll)); 
sample_lfcc( j) ■ calc_costs_sens (model); 

end 

figure 

%now, analyze the results 
%normalized histogram 
[n,bin_cent] = hist (san5)le_lfcc,25); 

n « n .* (l/(l€ngth(sample_lfcc)*(bin_cent(2) - bin_cent (1)))) ; 
bar (bin__cent,n) ; 

%format the plot 
max_occurance - max(n); 
min_center • min{bin_cent); 
max^center * max (bin_cent) ; 
x_span * max_center - min^center; 
xjnargin * 0.1*x_span; 
x^min * min^center - xjDoargin; 
x_max * max^center + x^margin; 
yjnin ■* 0; 

yjaax * l.l*max_occurance; 

axis ([xjDain x_max y_min yjnaax]) ; 

y_space » 1 inspace (yjnin ,0.5* y_max ,10); 

min_calc_lfcc « min (saBq>le_lfcc); 
max^calc^lfcc *max (sample_lfcc); 

NUM_STEPS - 100; 

mean_lfcc(batch_space) - mean (sanple^lfee); 
std_lfcc (batch_space) » std (sample_lfcc); 

mean__95_lfcc(batch_space) « mean_lfcc(batch_space) + 1.645* (std_lfee (batch^space)); 
mean_05_lfcc(batch“space) - mean]^lfcc(batch_space) - 1.645*(std_lfee(batch_space)); 

X « linspace(min_calc_lfcc,max_caic_lfcc,NDM_STEPS); 
y « normal^dist {mean_lfec (batch_space), std_lfcc (batch_space) ,X) ; 

hold on 

plot(X,y,*-c*,»LineWidth»,3) 

tit_str e {('Total Fuel Cycle Cost Distribution - * num2str (NUM_SAMPLES) * Samples : * 
num2str(model.batches) * Batches'], ... 
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[’mean cost = ’ num2str(mean_lfcc(batch_space)) ’ mean 95% limit = ’ 
num2str (mean_95_lfcc (batch_space)) ]); 
title{tit_str); 

xlabel('Total Fuel Cycle Cost mills/kWhre*); 
ylabel('Probability Density'); 

mean^plot = ones (10,1) . * mean_95_1 fee (batch_space) ; 
plot (meanjplot, y_space, * -m', ' LineWidth *, 2) ; 

legend('Total Fuel Cycle Cost Distribution','95% Cost Upper Confidence Limit') 


end 

figure 

plot (all_batches,mean_95_l fee, *-dr* LineWidth2); 
hold on 

plot (all_J)atches, mean_lfcc,' -sb',' LineWidth', 2); 
plot (alljDatches, mean_05_lfcc,' -og',' LineWidth', 2); 

title('Total Fuel Cycle Cost ~ with Uncertainty','FontSize*,14,'FontWeight','bold*); 
legendCCost 95^{th} percentile*,'Cost mean value’,'Cost 5^{th} percentile*) 
ylabel('Total Fuel Cycle Cost - mills/kWhre'); 
xlabel('Number of Batches'); 


Note that this function makes use of a utility function normal_dist.m. This function 
is used to oreate plot points for a normal curve with a specified mean and standard 
deviation. This is useful for providing the superimposed normal curves that are used in 
visualizing the Monte Carlo Analysis results. 


%normal__dis t. m 

ftinction y = normal^dist (mean, std,x); 

%function y = normal__dist (mean, std,x) takes as arguements the mean and standard deviation 
%of a proposed normal distribution. Also, a vector x - representing the discretized 
%domain (that part of the pdf to be plotted) 

y = (1/(sqrt(2*pi)*std)) •* exp(-(1/2).*((x - mean)/ std)-^2); 
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